El momento adecuado para el Planning Poker

El Planning Poker es un método de estimación basado en el consenso. Por eso recomiendo utilizarlo también para los elementos que requieren consenso, es decir, más para los Product Backlog Items que para las tareas de un Sprint Backlog. En este artículo vuelvo a hablar del Planning Poker y explico cuándo se debería llevar a cabo.

Razones para estimar User Stories

Estimar User Stories en un Product Backlog tiene dos razones:

1.) El Product Backlog puede priorizarse. Imagina dos Product Backlog Items que el Product Owner considera de igual valor. El elemento con menor coste se abordará primero. Las estimaciones de los elementos dependen, por tanto, de sus costes y pueden utilizarse para la priorización.

2.) La organización puede hacer predicciones a más largo plazo. El alcance del trabajo debe ser conocido para que el Product Owner pueda decir cuánto se puede entregar y cuándo.

¿Cuándo se debe jugar al Planning Poker?

Con la ayuda de los puntos mencionados anteriormente, se puede determinar cuándo un equipo debería hacer estimaciones. Por un lado, debería hacerse lo suficientemente temprano como para que se puedan cumplir ambas condiciones. Por otro lado, no debería hacerse antes de lo estrictamente necesario.

En la práctica, hay dos situaciones en las que un equipo debería jugar al Planning Poker.

Un buen momento para el Planning Poker es, por ejemplo, después de un taller de escritura de historias, en el que se han creado muchos Product Backlog Items. Estos talleres deberían realizarse aproximadamente cada trimestre.

Así, el Product Owner y el equipo pueden establecer un objetivo más grande (que no se puede alcanzar en un solo Sprint) y crear las User Stories necesarias para ello.

Normalmente, en un taller trimestral de escritura de historias se crean entre 20 y 50 Product Backlog Items. Si se pueden estimar unos 20 elementos por hora, se necesitan en total unas dos horas por trimestre para la estimación.

Además, el Planning Poker también puede realizarse una vez por Sprint. Algunos equipos lo hacen durante la reunión regular de Product Backlog Grooming. Esto es perfectamente válido, siempre y cuando todos los miembros del equipo participen.

Si no todos los miembros del equipo están involucrados, se puede jugar al Planning Poker después de un Daily Standup hacia el final de un Sprint. Si un equipo hace las estimaciones demasiado pronto durante un Sprint, es posible que tenga que repetir todo para las historias que se añadan más tarde.

Pero la estimación tampoco debería hacerse demasiado tarde. De lo contrario, el Product Owner no podrá tener en cuenta estos elementos al determinar los elementos para el próximo Sprint.

¿Cuándo no se debe jugar al Planning Poker?

Hay un momento que es desfavorable para el Planning Poker: al inicio de una reunión de Sprint Planning. En ese momento ya es demasiado tarde para que el Product Owner pueda orientarse en las nuevas estimaciones a la hora de establecer prioridades.

Puede haber Product Owners que puedan reordenar las prioridades en muy poco tiempo. Sin embargo, tener más tiempo siempre es mejor.

Otro problema es que un equipo casi siempre dedica demasiado tiempo a estimar cuando un Sprint Planning comienza con Planning Poker. Creo que esto se debe a que los miembros del equipo ya empiezan a pensar directamente en los detalles de sus User Stories.

Sin embargo, en el Planning Poker deberían dar una estimación menos detallada de sus User Stories. Es difícil dar una estimación tan general en una reunión cuando en realidad se deberían evaluar los Tasks con mucha más precisión.

Esto lleva a demasiadas discusiones innecesarias. Y eso, a su vez, hace que el equipo necesite mucho más tiempo que si se realizaran ambas cosas por separado.

Con estas directrices deberías ser capaz de encontrar el momento adecuado para el Planning Poker.

Este texto proviene del blog de Mike Cohn y fue traducido al alemán por nosotros.