Backlog de Scrum Sprint: propósito principal y ejemplo

Punto de partida

Renee ha aceptado recientemente un puesto como desarrollador en una empresa de software que utiliza Scrum como metodología de proyectos. Ella es nueva en Scrum y ha estado usando recursos educativos para familiarizarse con él. Como alguien que será responsable de completar el trabajo del proyecto, se enfoca en comprender cómo avanza el trabajo a lo largo del proyecto. Esto la lleva a la acumulación de sprints.

En Scrum , la forma más común de Agile, el trabajo del proyecto se completa en intervalos repetidos, generalmente de 2 a 4 semanas de duración, conocidos como sprints . Para que se complete en intervalos más cortos y frecuentes, el trabajo debe dividirse en una forma más manejable. Este formulario se conoce como una historia de usuario , que es un requisito del proyecto que se centra en la funcionalidad para un usuario específico. Las historias de usuario las escribe el propietario del producto , la persona que solicita el proyecto. Se mantienen en orden de prioridad en la cartera de productos que debe asumir el equipo de desarrollo.

A Renee le preocupa principalmente cómo asume el trabajo el equipo de desarrollo. En Scrum, esto ocurre al comienzo de cada sprint. El equipo de desarrollo se reúne con el propietario del producto en una reunión de planificación de sprints para revisar las historias de usuarios de alta prioridad en la cartera de productos. Una vez que el equipo los comprende completamente y está seguro de que se pueden completar durante el sprint, las historias de usuario se mueven de la cartera de productos a la lista de trabajos pendientes del sprint . Esta es la agrupación de trabajo que se desarrollará completamente y se probará durante el sprint, mantenido en orden de prioridad.

Maquillaje y ejemplo

A medida que Renee adquiere una comprensión de cómo se originan los retrasos en los sprints, pasa a analizar en qué consisten y cómo se utilizan. Estas preguntas no se pueden responder a través de materiales educativos, sino que deben provenir directamente de su equipo. Si bien hay puntos en común entre los trabajos pendientes de los sprints, varían de un equipo a otro. A medida que se concentra en la implementación, necesita conocimientos específicos de las prácticas de su equipo.

Una vez que las historias de usuario pasan de la lista de trabajos pendientes del producto a la lista de trabajos pendientes del sprint, el equipo de Renee las divide en tareas, que incluyen todo lo necesario para que se complete la historia del usuario. Las tareas suelen centrarse en el diseño o la codificación. Por ejemplo, si el equipo de Renee estaba trabajando en un sitio web minorista, una historia de usuario podría ser para la capacidad de un cliente para crear un inicio de sesión. Una tarea de diseño sería crear el diseño de la página web que usaría el cliente. Las tareas de codificación incluirían validar la información de inicio de sesión ingresada y almacenarla. Este proceso está completamente impulsado por Renee y su equipo. Depende del equipo determinar las tareas involucradas con cada historia de usuario, así como quién completará cada tarea.

Las tareas para cada historia de usuario avanzan a través de las etapas de finalización. Por lo general, existen diferentes estados que reflejan si el trabajo se está trabajando, probando o completando activamente. Esto a menudo se hace usando un tablero físico, conocido como tablero de tareas Scrum , donde las historias de los usuarios y las tareas se escriben en notas adhesivas y las diferentes etapas de finalización son columnas verticales en el tablero. También se pueden utilizar versiones electrónicas pero la clave es una representación visual de la obra y su progresión.

El equipo de Renee usa un tablero de tareas Scrum físico. Una historia de usuario y sus tareas asociadas comienzan en una columna denominada ‘Sprint Backlog’. A medida que se completan las tareas, están “en curso”. A partir de ahí, las tareas pasan a ‘Revisión por pares’, donde se verifica el código. Después de la revisión por pares, la historia del usuario y todas las tareas pasan a ‘En prueba’ donde se realizan las pruebas y, una vez que se completa, se mueven a ‘Hecho’. Es importante para su equipo tener una definición común de hecho y lo que es necesario para que las tareas y las historias de usuario progresen en el tablero.

Propósito

Una vez que Renee sabe de dónde proviene la acumulación de sprints y cómo lo aborda su equipo, lo último que busca comprender es por qué es beneficioso. Ella siente que esto es necesario para que ella acepte la acumulación de sprints. Ella podría saber todo lo que hay que saber al respecto, pero no podrá apoyarlo por completo sin comprender su valor. Los beneficios de la acumulación de sprints incluyen visibilidad y organización, así como una mayor eficiencia.

Los beneficios de la visibilidad son sencillos pero significativos. Al mostrar el progreso de las historias de usuario y las tareas, cualquiera puede ver rápidamente el estado actual del sprint. Para el equipo del proyecto, esto les permite identificar áreas que no están progresando y apuntar a ellas. Para las partes interesadas, esto proporciona una instantánea tangible cuando lo deseen. Los beneficios de la organización se derivan de la visibilidad. Las historias de los usuarios se mantienen en orden de prioridad, lo que permite al equipo centrar sus esfuerzos en lo más importante. Además, la representación visual de las tareas le da al equipo una imagen clara de qué trabajo debe hacerse y les permite ver si falta algo.

El beneficio adicional de la acumulación de sprints es que permite que el equipo sea más eficiente. Proporciona al equipo un único punto de referencia en cualquier momento. Esto es más eficiente si está buscando actualizar el estado del trabajo que está completando o si desea verificar el estado actual de algo. Además, en términos de estatus, requiere que el equipo use definiciones uniformes. Cuando Renee quiere saber si algo que ha desarrollado se ha probado, ya no recibirá respuestas de que casi está hecho o casi terminado, que son subjetivas y, a menudo, inútiles. En su lugar, simplemente puede hacer referencia al tablero de su equipo y ver si la historia del usuario está ‘En prueba’ o ‘Listo’.

Resumen de la lección

Scrum divide el trabajo del proyecto en historias de usuario , que se completan en sprints . Las historias de usuario las escribe un propietario del producto y se guardan en una lista de trabajos pendientes del producto. En una reunión de planificación de sprint , el propietario del producto y el equipo de desarrollo revisan las historias de usuario y las que se pueden completar dentro del sprint se trasladan al backlog del sprint . Estos se dividen en tareas, generalmente diseño y codificación. Las tareas pasan por etapas de finalización, como ‘En progreso’ y ‘En prueba’ hasta que se completa toda la historia del usuario. Las historias de usuario, las tareas y su progresión generalmente se representan físicamente en un tablero de tareas de Scrum. Este enfoque proporciona visibilidad, organización y mayor eficiencia.