El Product Backlog es un listado de todas las tareas que se
pretenden hacer durante el desarrollo de un proyecto. Todas las tareas deben
listarse en el Product Backlog para que estén visibles ante todo el equipo y se
pueda tener una visión panorámica de todo lo que se espera realizar en el
proyecto. El Product Backlog puede ser una lista de tareas desglosadas en
actividades según las características del proyecto, y destacando las que han
sido priorizadas y son más relevantes. Se añaden descripciones breves sobre
todo lo que se desea para el proyecto que se va a desarrollar y los
requerimientos necesarios para poder realizar las tareas. Nosotros lo hacemos en la hoja de cálculo de Google para compartir y gestionar en equipo. Hay que definir las tareas así como sus características; definición, hito y/o actividad a la que pertenece, comienzo previsto (nos permite hacer un cronograma previo), tiempo estimado, comienzo de la tarea, final de la tarea, tiempo real empleado, tipo de tarea (investigación, redacción, reunión, revisión, corrección, formación, etc.) y, sobre todo, un responsable de tarea (solo uno ya que las tareas deben tener un responsable). Para nombrar un responsable hay que saber definir la tarea en función del logro que tiene que conseguir esa persona. Si dos personas realizan una tarea extensa deben dividir esa tarea en dos tareas o subtareas para que cada uno haga su trabajo y se responsabilice de esa tarea. Este product backlog se irá desarrollando con más detalle el sprint backlog para definir las tareas y llevarlas al Trello para su gestión transparente.
Cuando aplicamos Scrum, no es necesario definir todos los
requisitos y tareas al inicio de un proyecto ya que pueden aparecer nuevas tareas no previstas o mal previstas. Pero siempre hay que comenzar con una previsión de tareas lo más detallada posible para tener una visión del proyecto y de su carga de trabajo para planificar de forma adecuada. Típicamente, el Product Owner, junto con el equipo, empieza escribiendo todo lo que consideran importante
en el Product Backlog. Este Product Backlog es casi siempre suficiente para
iniciar con el primer sprint. Y este Product Backlog tiene permitido crecer y
cambiar tanto como sea necesario, en función a lo que se va aprendiendo sobre
el producto y los clientes. El equipo determina qué tareas se pueden completar
durante el sprint que está por iniciar. El equipo mueve las tareas desde el
Product Backlog al sprint backlog correspondiente. Al hacerlo, puede que se
amplíe cada tarea del Product Backlog en más de una tarea para el Sprint
Backlog. Así el equipo puede distribuir el trabajo de forma más efectiva
durante el sprint. Todas estas tareas del sprint backlog pasarán a Trello para su realización por los responsables asignados.
Aquí tienes un video para ver el desarrollo del Product Backlog, aunque en nuestro trabajo práctico es mucho más sencillo aplicarlo: https://www.youtube.com/watch?v=_PWuSK2yiM0
El Sprint Backlog es un listado de tareas que proviene del desglose del proyecto que conforma el Product Backlog. Entendiendo como tarea, divisiones del trabajo que se puedan realizar en un plazo máximo de dos días y un mínimo de una hora; que sean atómicas en el sentido que se puedan finalizar sin necesidad de que sean dependiente de otras; que estén asignadas a responsables y así el equipo pueda saber de forma sencilla quien o quienes las están realizando; y que estén estimadas en tiempo para poder saber cuántas podremos añadir al sprint o para calcular la velocidad del equipo.
El objetivo final de un Sprint Backlog, es ser la fuente de tareas que se van a ir moviendo en el tablero de tareas (Trello). En el tablero se representa el flujo de trabajo y es una herramienta muy potente para que el equipo y los actores involucrados en el proyecto puedan hacer el seguimiento y tener una visión general del estado actual del proyecto.
Fuentes de información:
Programación y más. Recogido y adaptado el 10/02/21 https://programacionymas.com/blog/scrum-product-backlog
QUIJANO, Juan (2012) Recogido y adaptado el 10/02/21 https://www.genbeta.com/desarrollo/cuando-todos-son-ventajas-sprint-backlog-hablando-de-scrum
No hay comentarios:
Publicar un comentario