Cómo dividir las user stories en tareas para controlar mejor el sprint

Diariamente, el Product Owner define las funcionalidades en diferentes user stories, o historias de usuario, y aquellas que son demasiado grandes, las corta en otras lo suficientemente pequeñas como para aportar valor de forma independiente y encajar en un sprint.

Dividir se convierte en un acto reflejo para el Product Owner. Las necesidades inicialmente planteadas en el grupo de trabajo o trasladadas por stakeholders se descomponen luego en funcionalidades durante el Story Mapping  y, finalmente, en docenas de user stories listas para llenar los sprints.

Lo ideal es que un sprint esté formado de múltiples user stories pequeñas que no superen los 2 o 3 puntos de esfuerzo.

El objetivo es que las personas que desarrollan puedan trabajar en varios temas durante el sprint, que la persona que ejerce la responsabilidad de Product Owner pueda hacer pruebas a medida que pasan los días y que el gráfico Burn-down (o Burn-up) evolucione gradualmente y no a trompicones.

Sin embargo, a veces no es posible descomponer las tareas tan finamente.

Imagina un sprint en el que hay una y sólo una user story para cada persona desarrollando. Cada desarrollador estaría en su propio silo. El Burn-down se estancaría. El Product Owner carecería de visibilidad. El resultado sería un mini ciclo en V. 

Pero, ¿hay alguna forma de cortar estas user stories?

Una Definition of Done que ayude a dividir

Todo comienza con la Definition of Done (DoD) que el equipo acuerda y muestra en la parte superior del tablero Scrum. Para que el Product Owner pueda realizar las validaciones finales, una user story debe respetar cada uno de los elementos de la DoD. En mi equipo, tiene que pasar por las siguientes tareas, entre otras:

• Code review
• Tests de integración
• Tener en cuenta los comentarios de validación
• Preparación de la demo
• Borrado de la rama

De hecho, hemos definido que una historia de usuario sólo puede ser entregada al Product Owner si ha sido revisada y probada en integración, no sólo localmente. Entonces se considera como Done (Realizada) cuando no hay más comentarios sobre la tarea y está lista para la demo (que no la Sprint Review, ojo).

Y a partir de esta división inicial en tareas que realizamos de forma recurrente se estableció rápidamente otra división en tareas técnicas para cada User Story.

Durante el sprint planning, una vez presentadas las user story y las BDD, las personas que desarrollan discuten y hacen la descomposición en tareas técnicas para calcular el esfuerzo exacto.

El trabajo de diseño comienza tan pronto como se completa la planificación del sprint.

¿Qué gana el Product Owner?

Aunque estas tareas dependen unas de otras y no pueden probarse individualmente, esta descomposición no sólo interesa a las personas que desarrollan.

Gracias a esta división de tareas, ya no hay una user story que dure todo el sprint y que bloquee al desarrollador en un sólo tema durante todo el periodo.

Se acabaron las monótonas reuniones diarias que impiden tener una visión general a lo largo del tiempo. Se acabó el efecto túnel. Bienvenido a la organización y a la producción rápida de valor.

Una historia de usuario grande ya no es un riesgo, permite que varios desarrolladores trabajen en el mismo tema, permite el intercambio y el desafío. Cada una de sus tareas vive en el tablero. La visibilidad que aporta esta descomposición permite anticiparse y evitar riesgos.

En nuestro equipo, hemos optado por calcular el esfuerzo de la user story y no de las tareas para evitar largas sesiones de debate. Esta estimación se reparte en las tareas y, cada mañana, se vuelve a calcular el trabajo restante en cada tarea.

Una tarea rara vez supera los 2 puntos de esfuerzo, lo que permite a cada desarrollador cambiar de tema con regularidad y participar en todo el ámbito del sprint, adquiriendo así competencia en todos los temas.

Si las tareas no se pueden probar individualmente, esta descomposición permite controlar mejor el sprint y su organización, el Product Owner puede anticipar las historias de usuario "done" y organizarse para probarlas y hacer comentarios.

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

¿Un gráfico Burn-down para las tareas o las user stories?

En mi equipo, el gráfico Burn-down se actualiza con el número de tareas y, al final del sprint, una user story inacabada no se cuenta como cero, sino con el número de puntos completados. Sigue clasificándose como “Not Done" y las tareas inacabadas pasan al siguiente sprint.

Me parece que este gráfico Burn-down en "tasks" permite un mejor seguimiento del progreso del sprint; la curva suele descender de forma natural.

Sin embargo, no debemos caer en la trampa de terminar un sprint con un número máximo de puntos, en el que todas las user stories han sido iniciadas pero no completadas.

A este gráfico Burn-down en tareas le añadiría, pues, el indicador del número de user stories "Done" en el sprint.

El objetivo de un sprint es producir valor, no ganar puntos.

¿Y tú, cómo gestionas y haces seguimiento de las user stories de gran tamaño?

Para saber más: descarga nuestro libro Las Claves del Product Management

Foto de Christina @ wocintechchat.com en Unsplash