Los equipos de Scrum suelen comprometerse a realizar historias, las cuales luego las descomponen en tareas. Estas tareas son estimadas y re-estimadas a diario para actualizar el gráfico de Burndown. Pero no todo es tan bonito y simple. Muchas veces, crear estas tareas es algo que simplemente apesta. ¿Hay alternativas?
Scrum sin tareas
Los desarrolladores que usan Scrum suelen dividir las historias en tareas para facilitar la distribución de la implementación en todo el equipo, y poder realizar un seguimiento del progreso con un nivel de detalle mayor. Desafortunadamente, una historia puede explotarse en una lista grande de tareas no triviales, de forma que la misma historia no pueda completarse al finalizar la iteración. Ron Jeffries sugiere una alternativa: Usar a las historias como unidad, y no descomponerlas en tareas.
Para que esto de resultado, las historias tienen que ser lo suficientemente pequeñas para que el equipo las pueda comprender y estimar sin problemas. Una posiblidad es descomponer la historia en una lista de criterios de aceptación, y luego ver los elementos de esta lista y encontrar aquellos pue puedan ser historias por si mismos. Si un criterio de aceptación en particular añade valor al producto, es visible para el usuario, y es testeable, entonces es un buen candidato para convertirse en una historia.
De esta manera, si las historias son pequeñas, entonces no se necesita hacer un seguimiento en el burndown a nivel de tareas, sino de historias directamente.
Quemas historias, no tareas
El resultado de este pensamiento es cambiar el simple: "Quemar historias, no tareas". Cuando se hace un seguimiento a nivel de tarea, los desarrolladores pueden "hacer su parte", terminando muchas tareas, sin que se entregue ninguna funcionalidad. Por otro lado, si el equipo hace un seguimiento sólo de historias terminadas, los desarrolladores recien logran la satisfacción de "finalizado" cuando se completa una historia. Esto además promueve una idea mucho más valiosa de la "Definición de Terminado".
