Estimación de tareas en Scrum

Por Rubén de la Torre
Jefe de proyecto de OpenSistemas

Este aspecto de Scrum, la estimación de tareas, es el que menos claro me ha quedado siempre de todas las características de esta metodología ágil y que, de hecho, ha generado muchos debates con mis compañeros de trabajo e incluso. bastantes críticas a esta parte de la metodología.

Tras documentarme sobre este asunto, en este artículo pretendo explicar cómo es la estimación de tareas en Scrum y finalmente dar mi opinión sobre el mismo.

¿Cómo es la estimación de tareas en Scrum?

Primeramente y sin entrar en mucho detalle, doy las primeras pinceladas de cómo se realiza la estimación de tareas en Scrum.

Las tareas en Scrum se estiman con una técnica llamada Planning poker o Scrum poker, para la cual cada participante tiene una baraja con las siguientes cartas ½, 1, 2, 3, 5, 6, 7 e infinito. En la estimación de cada tarea cada participante, y al mismo tiempo, pone boca arriba la carta con el número de horas que cree que se necesitan para realizar completamente la tarea.

  • Si la estimación de la tarea resulta ser infinito significa que la tarea ha de ser dividida en varias tareas más pequeñas.

  • Si las estimaciones son muy dispares, es necesario abrir el debate y que los participantes que han realizado las estimaciones más alejadas de la media justifiquen su elección y aclarar con el propietario de producto o cliente el alcance de la tarea con el fin de ir consiguiendo aproximar las estimaciones de los miembros del equipo.

  • Finalmente, se debe llegar a un consenso o, si el grupo es grande y no se logra un consenso, se puede optar por tomar una decisión más conservadora (la mayor) o la media.

Aspectos cuestionables de Planning poker

a) Valores no presentes

He encontrado diversas variantes sobre la serie de posibles valores que se puede usar para realizar la estimación, como las siguientes:

  • 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (no estoy seguro) y café (necesito un descanso)

  • 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 (serie de Fibonacci)

  • ½, 1, 2, 3, 5, 6, 7 e infinito

  • O la que ofrece la aplicación móvil Scrum Poker de Android como “Estándar”

scrum-poker

El problema lo explico con el siguiente ejemplo, y es que si yo opino que la tarea X requiere 70 horas, y estamos usando la última serie mostrada, me veo obligado a elegir 40 o 100, ambas opciones lejos de mi impresión.

Mi opinión al respecto

Para evitar este problema basta con utilizar una serie como la siguiente

  • 1, 2, 3, 4, 5, 6, 7 e infinito

De manera que se marque como último valor el que se considera como máximo aceptable para una tarea y que existan todos los valores intermedios hasta 1 e infinito por si se considera que el esfuerzo para realizar la tarea es superior a las opciones anteriores, en cuyo caso habría que descomponer la tarea en varias.

Es decir que jugando con los valores que se incluyen en la serie se puede ajustar a la realidad del proyecto en el que trabajamos.

b) Poco profesional

Este es posiblemente el aspecto que más debate ha suscitado y es que ninguno vemos muy presentable, estar un grupo de compañeros, “jugando” a las cartas en el entorno de trabajo y aunque está claro que no se trata de un juego, yo personalmente no lo veo adecuado en ninguno de los proyectos en los que he trabajado, aunque también es cierto que esto puede ser solo un problema de falta de costumbre.

Mi opinión al respecto

Se puede realizar la estimación sin necesidad de utilizar las cartas, simplemente con que cada miembro pronuncie al mismo tiempo su elección en voz alta y a partir de ahí se continúe con normalidad, es decir debatiendo las alternativas hasta llegar a consenso. Entiendo que con un grupo maduro e idealmente con pocos miembros esta opción es perfecta.

De manera alternativa, se puede usar cualquiera de las aplicaciones para móvil, como la que se mencionaba anteriormente, aunque esta solución solo disminuye parcialmente la apariencia frívola de la tarea, puesto que un grupo de por ejemplo 6 ú 8 personas en círculo y móvil en mano tampoco ofrecen la imagen más profesional.

En general creo que este problema tampoco es importante.

c) Motivo psicológico

El que he llamado motivo psicológico se refiere a que la manera de estimar que se plantea, puede llevar a los participantes a la opción acomodada de estimar algo con una puntuación media y que no le exija así la implicación necesaria para que la estimación sea todo lo real que se necesita.

Mi opinión al respecto

Este es seguramente el aspecto más difícil de defender o de criticar, puesto que no deja de ser opinable como puede afectar esta tarea a una persona, pues depende de muchas variables, como de su confianza personal, de su implicación, de la confianza que recibe en su entorno, etc.

Pero en general veo menos motivos negativos que positivos, por ejemplo:

  • Se crea implicación dentro del equipo, puesto que todos los miembros del equipo participan.

  • Al votar de manera “síncrona” todas las opiniones tienen el mismo peso y no se ven afectadas por las de los miembros más dominantes del grupo.

  • Se fomenta la discusión lo que ayuda a tener en cuenta todos los detalles

  • Se consigue aceptación sobre la estimación por parte del equipo

d) Legitimidad

Por último, y como resultado de la labor de documentación realizada para escribir este artículo, me planteo la legitimidad de Planning poker como parte de la Scrum. En la documentación que había leído de Scrum y en los cursos que he realizado siempre he encontrado esta planificación como parte de la metodología, pero en realidad no he encontrado referencias a ella en los principales sitios Scrum, como son los siguientes

De hecho, actualmente en la página siguiente de la wikipedia se informa de que el artículo está sin verificar y como comentaba antes el artículo no está enlazado desde la página principal de Scrum, como sería esperable

Mi opinión al respecto

Este último problema no lo enfoco tanto como un problema sino como una observación, y quizá es por todas las dudas antes expresadas o incluso por la poca trascendencia que tiene dentro del modelo como se estimen las tareas, por lo que no se ha incluido entre las características generales de Scrum en los principales sitios web que he consultado y mencionado anteriormente.

Conclusión

Una de las principales características de Scrum es que se puede y de hecho se debe adaptar la metodología a las necesidades de la empresa o proyecto donde se quiere utilizar y casi todos los problemas antes mencionados se pueden explicar bajo esta premisa.

En definitiva, creo que el modelo de estimación de Planning poker de Scrum es en general correcto, pero que bajo mi humilde opinión tiene alguna fisura, por lo que es importante adaptarlo a las características del proyecto donde se vaya a usar.