A veces veo algunos equipos obsesionados con la planificación del sprint, especialemente con la estimación de las tareas. Quiero decir, realmente obsesionados. ¿Dos días de planificación para un sprint de dos semanas? Aunque no lo crean, ocurre. Incluso aunque se quejan de pasar mucho tiempo en las reuniones de Scrum, insisten y discuten los detalles de la estimación de cada tarea. Por suerte, para aquellos equipos que quieran aprovechar su experiencia en Scrum y en las planificaciones, eliminar la estimación de tareas es una opción.
No, no miren con desconfianza. No es pecado preguntarnos sobre estimar o no estimar las tareas. Y es posible dejar de hacerlo. Igual, antes un detalle importante: para quienes son nuevos en Scrum, no les recomiendo eliminar la estimación de tareas hasta que no logren tener una velocidad estable.
Sin embargo, una vez que se logra una velocidad estable, se pueden usar los conceptos de puntos de historia y de velocidad para eliminar la necesidad de estimar las tareas durante la planificación del sprint. Ese tiempo que se dedica a estimar tareas se puede aprovechar mejor construyendo software. Vamos a ver una serie de pasos para eliminar de manera gradual la estimación de las tareas en el proceso de planificación de los sprints.
El objetivo de la planificación del sprint
Antes de comenzar, repasemos los motivos por los cuales hacemos las planificaciones de los sprints de cierta manera. La idea es poder asegurárnos de que sigamos cumpliendo con estos objetivos cuando agilicemos el proceso. Planificamos los sprint para crear lo siguiente:
- Un entendimiento compartido en todo el equipo sobre las metas del sprint.
- Un entendimiento compartido del trabajo que necesita hacerse durante el sprint.
- Un entorno en el cual los miembros del equipo sepan qué hacer a continuación (o lo puedan averiguar en segundos).
- Un compromiso grupal cumplible para entregar cierta cantidad de valor, expresada como elementos del backlog del producto.
- Un gráfico de burndown para hacer un seguimiento del avance a través del sprint.
La estimación de tareas contribuye al punto 5, y para algunos equipos también al punto 4. Si logramos cumplir con estos dos elementos sin crear estimaciones de tareas, entonces seremos libres para elegir no estimar más las tareas, ¿no?. Si están de acuerdo, a continuación vamos a ver una posible transición para eliminar la estimación de tareas de las planificaciones de sprints.
Paso 1: Establecer una velocidad estable
Empezar usando el proceso normal de planificación de sprint, ya sea que tome dos días o dos horas, para cada sprint hasta lograr demostrar una velocidad estable. Es bueno asegurarse que el equipo pase la Prueba de Nokia y que construya software potencialmente productivo en cada sprint (en otras palabras, probar que podemos calcular la velocidad de forma correcta). Cuando logremos una velocidad estable, el equipo va a poder hacer y cumplir compromisos de sprint basándose sólamente en su velocidad demostrada y en las estimaciones de los elementos del Backlog del Producto. Esto se logra de todas formas como parte de tener una buena implementación de Scrum, ¿no?.
Paso 2: experimentar con un burndown basado en tareas
Cuando pensemos que ya estamos listos para dejar de estimar tareas, comencemos usando dos gráficos de burndown en vez de uno. Continuamos usando el gráfico de burndown normal basado en esfuerzo restante (el cual está basado en las estimaciones de las tareas del backlog del sprint). Agregamos un nuevo gráfico de burndown, el cual estará basado sólo en la cantidad de tareas del backlog del sprint, sin importar sus estimaciones. Este nuevo grafico de burndown puede llamarse "gráfico de burndown basado en tareas".
El gráfico tradicional de burndown basado en esfuerzo tiene el total de las estimaciones de todas las tareas para el sprint y, como las estimaciones se actualizan diariamente, el gráfico continua reflejando el esfuerzo restante estimado que queda en el sprint. Si todo sale bien va a tender a cero. En cambio, el nuevo gráfico de burndown basado en tareas tiene la cantidad total de tareas en el sprint. No se actualizan las estimaciones para este gráfico, y el trabajo se quema cuando se completa una tarea. Para lograr mejores resultados, hay que armar las tareas lo más pequeñas posibles. El gráfico de burndown basado en tareas refleja la cantidad estimada de tareas que quedan hacer en el sprint, y no es esfuerzo restante. Esto funciona mejor si hay muchas tareas pequeñas, usualmente aquellas que puedan hacerse en un día o menos.
Hay que asegurarse que ambos gráficos de burndown concuerden y den la misma visiblidad del progreso del equipo durante el sprint. Si el gráfico de burndown basado en tareas no está resultando útil, fijate en el Paso 3.
Paso 3: achicar las tareas para mejorar el burndown basado en tareas
Un buen gráfico de burndown basado en tareas depende en que existan tareas pequeñas para quemar. Conceptualmente, si tenemos una sola tarea por elemento del Backlog del producto, vamos a tener un burndown basado en esfuerzo perfecto y sin problemas, porque las estimaciones de las tareas se actualizan diariamente (ahora, si los elementos del Backlog del Producto realmente tienen una sola tarea, hay un problema con las historias o con la descomposición de tareas). En cambio, en esa situación el gráfico de burndown basado en tareas no va a brindar detalles del trabajo diario, porque las tareas van a tender a llevar varios días, y el progreso sólo se registra cuando se termina una tarea. La solución es armar tareas más pequeñas. Una buena regla es que una tarea debería poder completarse en un día o menos.
Paso 4: dejar de hacer la estimación de tareas
Cuando ambos gráficos de burndown brinden información similar y cuando podamos realizar entregas de compromisos basados en la velocidad del sprint, recién entonces podremos dejar de estimar las tareas y tirar el gráfico de burndown basado en esfuerzo. A algunos equipos les va a resultar facil de lograr, a otros les puede llevar varios sprints. La clave es utilizar correctamente la idea de la velocidad. Seguiremos haciendo la descomposición de historias en tareas, sólo que no las estimaremos. Ahora bien, eliminar la creación de tareas es un paso completamente diferente (pero también realizable).
¿Qué perdimos al quitar la estimación de tareas? La estimación de tareas ayudaba a los puntos 4 y 5 de la lista anterior. Todavía tenemos un gráfico de burndown para realizar el seguimiento del progreso, así que el punto 5 está cubierto. También quitamos la necesidad de soportar el punto 4 porque el equipo ha demostrado su habilidad de comprometerse basándose en las estimaciones de los elementos del Backlog del Producto, y no necesita estimar las tareas para validar.
Lo único que podría perderse es el soporte tangencial para la planificación del punto 2. Es decir, al no realizar las estimaciones, podemos estar quitando algo de presión mental y motivación para analizar las tareas en profundidad, buscar problemas, recordar esfuerzos similares, y en general traer conocimiento y experiencia al momento de planificar las tareas. ¿Es importante? ¿Va a ocurrir? Estas son preguntas que cada equipo debe responderse en forma individual.
