Sprint Backlog
La metodología Scrum está caracterizada por un alto nivel de organización y el avance sobre eventos bien establecidos, en un orden específico, con tiempo determinado y con un objetivo específico.
Del Sprint Planning, uno de los eventos de Scrum, resulta el Sprint Backlog, o como muchos le conocen, pila de tareas.
Esta lista de actividades es la que se realizará en el Sprint que se esté planificando; su correcta organización es vital para el buen desarrollo del proceso.
Este Sprint Backlog contempla todas las actividades y, establecido el tiempo de duración del Sprint, se puede determinar cuánto se avanzará en el desarrollo del producto en este intervalo de tiempo.
¿De dónde nacen las actividades que se incluyen del Sprint Backlog?
De una reunión previa en donde conjuntamente el Product Owner y el Scrum Team acuerdan el desarrollo de determinadas historias de usuario que se desarrollarían en el Sprint.
La misión del equipo de desarrollo es descomponer las historias en actividades puntuales que se puedan hacer en un tiempo determinado para satisfacer los acuerdos de cada historia.
Es por esto que, las actividades dentro de un Sprint Backlog cuentan con las siguientes características:
- Cada actividad debe terminarse en un tiempo máximo de dos días. El mínimo de tiempo para cada actividad es una hora, por lo que esto determinará la división de cada historia de usuario.
- Cada actividad debe ser independiente. Aunque forme parte de un todo, la tarea debe poder realizarse sin que dependa de otra, al menos no deberá depender de otra actividad dentro del Sprint.
- Cada actividad se asigna a un miembro del equipo de desarrollo, permitiendo que todo el equipo sepa qué está haciendo quién.
- Por último, es importante asignar un tiempo estimado a cada actividad. Recordemos que cada Sprint puede durar dos semanas, por lo que, es importante saber cuánto tardaremos en completar cada actividad para poder hacer la asignación de tareas de tal manera que cada miembro cumpla con su cuota de trabajo. El tiempo estimado también servirá para evaluar la velocidad de trabajo de los miembros del equipo.
Como se mencionó anteriormente, esta pila de tareas nace del Sprint Planning que no es más que una reunión de planificación.
En esta reunión, todo el equipo va analizando historia por historia, de forma funcional y técnica y siempre teniendo presente la prioridad de cada una. De este análisis nacen las tareas estimadas que tendrán un tiempo de culminación aproximado.
Esta reunión es muy importante, pues las historias de usuarios suelen ser construcciones sencillas que expresan los requerimientos del producto, pero no es hasta que se estiman las actividades que satisfacen esa construcción que se sabe cuáles son los requisitos técnicos para lograr el objetivo.
Asimismo, en el Sprint Planning se decide cual será la estrategia para la construcción del producto.
Es probable que, en una historia de usuario de un software, el análisis determine que el equipo debe usar un nuevo programa o debe elegir entre dos tecnologías distintas.
Al finalizar la reunión, el Sprint Backlog está listo y el equipo se ha asegurado de aprovechar todo el tiempo que tienen agregando tantas actividades como sean posibles.
Una de las herramientas que se usan para monitorear el avance es un tablero de Scrum en donde se visualizan las tareas ordenadas por prioridad y sobre una línea de tiempo.
¿Cómo se construye un Sprint Backlog?
¿Cómo se usa en el día a día del Sprint Backlog?
Las reuniones diarias sirven para actualizar la información sobre el trabajo realizado y pueden modificar el tablero o la pila de actividades de acuerdo con el desempeño del equipo.
Como ya sabemos, en una reunión diaria o Daily Scrum meeting, cada miembro habla de lo que hizo el día anterior, de lo que hará hoy y de si tiene algun impedimento que le permita completar su trabajo.
Esta interacción se basa en la lista de actividades que ha realizado y, como existe una estimación de tiempo, es muy sencillo darse cuenta si está dentro del tiempo estimado, si ha avanzado más rápidamente o si lo ha hecho más lento de lo esperando.
Dependiendo de la experiencia de cada equipo de desarrollo, esta reunión sirve para actualizar el tablero de tareas, aunque algunos equipos más experimentado van eliminando tareas en tiempo real; en este sentido, existe cierta similitud con el Kanban.
Si la situación general del Sprint es que existe un retraso en las actividades porque, por ejemplo, aparecieron limitaciones ocultas en la revisión o en la implementación, entonces se tomará la decisión de eliminar tareas que no sean prioritarias.
Es importante que se haga en esta reunión porque el equipo es el responsable del éxito de la iteración, no es la decisión de uno solo.
Diferencia entre Product backlog y Sprint Backlog
Aunque ambas son pilas de tareas, cada una sucede en un momento distinto del Sprint y tienen objetivos distintos.
Por su parte, el Product Backlog es creado por el Product Owner, cuya misión principal es maximizar el valor del producto desarrollado para que resulte en un mejor retorno de la inversión para el cliente que representa.
El Product Backlog se presenta, idealmente, en historias de usuarios en forma de oraciones cortas que toman en cuenta quién realizará la acción, la acción y la respuesta esperada al realizar la acción.
En una primera reunión, el Product Owner explica las historias y se acuerda cuántas de ellas se puede incluir en el Sprint basándose en su complejidad.
El Sprint Backlog es la pila de tareas que se genera a partir del Product backlog, en el cual se desmenuza cada historia y se convierte en actividades puntales que se realizan para satisfacer las especificaciones de cada historia.
¿Qué es el Sprint Review?
Scrum tiene cinco eventos clave y uno de ellos es el Sprint Review.
Esta reunión está relacionada con el Sprint Backlog porque en ella se evalúa el resultado del equipo de desarrollo. El Sprint Review ocurre al terminar el Sprint y busca validar el incremento del producto.
Asimismo, dependiendo del resultado, se reevaluará el Product Backlog, el cual incidirá en el próximo Sprint.
En esta reunión, que dura una hora por cada semana de Sprint, se muestra al Product Owner el avance y él determina si cumple con los objetivos de la historia del usuario.
Para que el Sprint Review tenga verdadero valor, no solo debe ser una demostración de lo que se espera que sea el producto, la funcionalidad debe estar terminada.
Si la historia es “como usuario quiero una sección en donde pueda ingresar el nombre de un artículo y que la aplicación me del precio y la disponibilidad” la demostración debe confirmar que se puede realizar tal acción.
Asimismo, en esta reunión no solo se evalúa el incremento del producto, sino el impacto de ese avance sobre el negocio, recordemos que se trata de dar valor al producto.
Si bien, desde las historias existe priorización, no deja de ser cierto que el equipo puede tender a realizar lo que suponga más incremento y no lo que agregue más valor.
¿Qué es el Sprint Retrospective?
Una vez que finaliza el Sprint Review, sigue el Sprint Retrospective, la cual es la última reunión del Sprint.
Esta reunión sirve para evaluar el desempeño del equipo.
Anteriormente, destacamos que el equipo de desarrollo es quien divide en actividades las historias de usuarios, pero esta práctica no es infalible, por lo que, en el Sprint Retrospective se podrá determinar qué funcionó, qué no, y qué se puede mejorar en el próximo Sprint.
En esta actividad no participa en Product Owner; el Scrum master es quien garantiza que todas las reuniones cumplan con los fundamentos de la metodología.
