No estimes el Sprint Backlog con Task Points

Cuando escribí el libro Agile Estimating and Planning en 2005, ya había trabajado con diferentes métodos de estimación durante cinco años. Después de realizar experimentos con varios equipos, especialmente con los que trabajaban directamente para mí, sentí que había aprendido lo suficiente como para escribir el libro.

Sin embargo, aún había mucho que no sabía (¡y por supuesto aún ahora también!). Por eso busqué equipos que estimaran y planificaran sus proyectos de manera diferente a como yo lo hacía. Algunos de estos equipos usaban Task Points además de Story Points para estimar sus Product Backlog Items.

Eso me pareció interesante. En aquel entonces ya era un defensor de los Story Points, y desde entonces me he convertido en un fan aún mayor gracias a las ventajas de los Story Points. Sin embargo, simplemente no podía entender por qué un equipo usaría Task Points. Pero como era tan fan de los Story Points, quería descubrir más sobre los equipos que trabajaban con Task Points.

Logré convencer a algunos equipos de que me dejaran observarlos para aprender más al respecto.

Lo que descubrí confirmó mi suposición de que los equipos no deberían estimar sus Sprint Backlog Items con Task Points.

La principal ventaja de los Story Points

La principal ventaja de los Story Points es que personas con las más diversas habilidades, niveles de experiencia y diferentes antecedentes pueden dar conjuntamente una estimación de su trabajo.

Tomemos un ejemplo no del todo serio e imaginemos que quiero estimar junto con un pulpo cuánto esfuerzo sería lavar mi coche.

Un pulpo tiene cuatro veces más brazos que yo. Así que el pulpo debería poder lavar mi coche cuatro veces más rápido que yo. (Ya dije que no era un ejemplo muy serio. Pero espera).

El pulpo también podrá lavar cualquier otro coche cuatro veces más rápido que yo. Así que el pulpo y yo quizás podamos ponernos de acuerdo en que mi pequeño biplaza recibe unos cinco Story Points y un coche algo más grande recibe diez puntos.

Los Story Points permiten al pulpo y a mí ponernos de acuerdo en una cierta cantidad de puntos, aunque el pulpo sea sin duda mucho más rápido que yo.

Task Points

En los equipos que observé, noté que un Task Point era casi lo mismo que un Story Point. Sin embargo, todos los equipos con los que hablé querían usar una unidad más pequeña que los Story Points.

Por ejemplo, un equipo que completa diez Story Points por Sprint podría lograr unos 80 Task Points por Sprint.

Los equipos simplemente querían una unidad más pequeña y granular para poder seguir mejor su progreso. Es similar a si el velocímetro del coche indicara la velocidad en años luz por hora. De esa manera, sería muy difícil determinar si estoy respetando el límite de velocidad o no.

Usar unidades más finas fue una buena idea para muchos equipos. Después de todo, es bastante difícil medir el progreso diario de un equipo con Story Points cuando, por ejemplo, completa siete Story Points en dos semanas. En este caso, los Story Points son simplemente una unidad demasiado grande para ser útil.

¿Y las horas?

Pero ya existe una unidad más fina con la que todos los miembros del equipo ya están familiarizados: las horas.

Cuando observé a los equipos estimando con Task Points, noté que esto no tenía ninguna ventaja en comparación con estimar los Sprint Backlog Items en horas.

Hay una diferencia fundamental entre los Product Backlog Items (generalmente en forma de User Stories) y las tareas del Sprint Backlog: en un Product Backlog Item trabajan normalmente de tres a cinco personas; quizás uno o dos programadores, un tester y posiblemente un diseñador, arquitecto, analista o redactor técnico, etc. En una tarea normalmente trabaja una sola persona.

Eso significa que no todos los miembros de un equipo necesitan dar conjuntamente una estimación para una tarea, como sí lo harían para un Product Backlog Item. Todos en el equipo tienen la posibilidad de dar una estimación para la tarea, pero solo quien finalmente trabaje en ella puede dar la estimación definitiva.

Si es muy probable que solo una persona específica trabaje en una tarea, entonces se debería tomar la estimación de esa persona. Si dos o tres personas van a trabajar en una tarea, se deja que las tres den una estimación conjunta o se toma la estimación de la persona que más probablemente realizará el trabajo.

Si el trabajo se delega a otra persona durante el Sprint, las estimaciones simplemente cambiarán en el peor de los casos. Si un miembro del equipo más rápido asume el trabajo de un colega más lento, cambia la estimación de ocho a cuatro puntos, o viceversa.

¿Por qué no usar Task Points?

Los Task Points, por lo tanto, no tienen ventajas sobre las horas. Sin embargo, tienen desventajas frente a los Story Points:
- Muchos miembros del equipo no están familiarizados con ellos.
- Es necesario contar con valores de referencia para poder hacer estimaciones.
- Existe el riesgo de que las estimaciones dejen de orientarse por los valores de referencia originales con el tiempo.

Mi consejo sobre los Task Points

Terminé mi incursión en el mundo de los Task Points sin que me convencieran de su valor. Sigo siendo un defensor del Sprint Planning orientado al compromiso, tal como lo conocemos. Quizás "Sprint Planning orientado a la capacidad" sea un mejor nombre. En mi opinión, tiene ventajas considerables frente al Sprint Planning orientado a la velocidad.

Para la mayoría de los equipos, el Sprint Planning orientado al compromiso o a la capacidad funciona mejor con horas. Algunos equipos siguen este proceso pero omiten las estimaciones y solo las usan en reuniones para determinar qué pueden incluir en el Sprint.

Otros equipos simplemente no estiman los Sprint Backlog Items en absoluto. Cada uno de estos enfoques puede funcionar bien una vez que un equipo ha ganado experiencia con él.

Me alegro de haber realizado este proyecto para aprender más sobre los Task Points y los equipos que los utilizan.

Cuando examino métodos alternativos de estimación, siempre me decepciono un poco cuando un nuevo enfoque no es mejor que uno existente. Pero lamentablemente eso ocurre con bastante frecuencia.

Y sin embargo, encontraremos las mejoras continuas que todo agilista busca, si consideramos tantas opciones diferentes como sea posible.

Este texto proviene del blog de Mike Cohn y fue traducido por nosotros al español.

Product Owner: tareas y desafíos

=> Descubre qué hace un Product Owner durante todo el día.

¿Qué es una Scrum Story?

=> Descubre aquí las diferencias entre User Stories, Epics y Themes.