¿Usas Planning Poker para estimar tareas? Quizá deberías pensarlo mejor

¿Estás usando Planning Poker para estimar tareas en el Sprint Backlog? Quizás deberías replanteártelo. Es una herramienta que puede ser muy útil a la hora de estimar historias de usuario o elementos del Product Backlog. Pero las características de las tareas en el Sprint Backlog son bien distintas de las de los elementos del Product Backlog, y por lo general Planning Poker, o cualquier otra herramienta de estimación que se base en órdenes de magnitud, no es adecuada para dar soporte a estas estimaciones.

image

Las principales razones por las que Planning Poker no es una buena herramienta para estimar tareas son:

  • Las estimaciones de tareas se dan por lo general en horas, y por la propia naturaleza de las tareas, deberían estar en el rango de unas pocas horas, desde menos de una hora a un máximo de unas 16 horas. Es decir, las estimaciones de las tareas no crecen necesariamente en órdenes de magnitud, tal y como lo suelen hacer las estimaciones de las historias de usuario, sino que se mantienen en una magnitud pequeña. En Planning Poker tenemos sólo unas cuantas cartas para el rango de estimaciones pequeño, y además tenemos cartas para dar estimaciones grandes, que no deberían ni siquiera aparecer si las tareas han sido descompuestas adecuadamente.
  • Como consecuencia de lo anterior, al estimar tareas con Planning Poker vamos a echar en falta algunos valores que no están presentes (a propósito) en una baraja de Planning Poker, ya que para estimar tareas necesitaremos un rango de valores más preciso que para estimar historias de usuario. Por ejemplo no vamos a poder dar una estimación de 4 o de 6 horas para una tarea, lo cual a priori debería ser perfectamente posible. Me he encontrado con equipos que estaban incluso sacando más de una carta cada vez para poder llegar a la suma deseada para la estimación, lo cual demuestra la poca utilidad de la herramienta para este fin.

Por lo tanto, lo adecuado sería dejar Planning Poker, y otros métodos basados en órdenes de magnitud como T-Shirt Sizing, para estimar historias de usuario. Para estimar tareas podemos usar simplemente Wideband Delphi, o herramientas incluso más simples como analogía, desagregación u opinión del experto.

Aparte de esto, incluso podría ser discutible si es mejor estimar tareas en grupo o hacerlo individualmente. El mismo Ken Schwaber nos recomienda lo segundo (http://kenschwaber.wordpress.com/2010/10/ , Ejemplo 2), aunque esto daría para mucho debate.

Y por último, recuerda que a veces lo mejor es ni siquiera estimar las tareas. Las estimaciones no son valor que podamos entregar al cliente, sino más bien desperdicio, y si podemos permitirnos planificar adecuadamente sin tener que hacer el esfuerzo de estimación, estaremos ganando ese tiempo para avanzar en la entrega de valor. Algunos equipos simplemente descomponen el trabajo en tareas de un tamaño similar, con lo que la planificación se puede basar en contar las tareas que vamos a ser capaces de sacar adelante.

Os dejo con las slides de mi sesión sobre estimación ágil en el último TechEd de Oriente Medio; habla más bien de estimación para historias de usuario, pero los conceptos son útiles en sentido general.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *