1

Planning poker

Posted by David Doctor on lunes, diciembre 07, 2009 in , ,
Hemos comenzado un nuevo proyecto y el otro día tuvimos la primera sesión de estimación de las historias de usuario, en nuestro caso utilizamos planning poker como método de estimación, cada componente del equipo que va a desarrollar tiene una baraja de cartas y cada carta tiene un estimador. Los estimadores siguen una serie de Fibonacci para que seamos conscientes de que una estimación nunca será exacta y se transmita la incertidumbre que tenemos sobre el proyecto.



En nuestro caso esta estimación se hace al principio del proyecto para proporcinarle al dueño del producto los puntos de usuario de cada una de sus historias, evidentemente se harán más reuniones de este tipo a medida que aparezcan nuevas historias de usuario.

La técnica ya se explicó en un post anterior, pero después de la cantidad de reuniones que hemos tenido de este tipo quiero compartir algunas conclusiones:

1.- Si haces reuniones muy largas la convergencia en las estimaciones empiezan a aparecer sencillamente porque la gente está cansada, cuando veáis que en la primera tirada cada uno saca un estimador y terminan convenciéndose sin casi argumentos es hora de dejar la reunión para otro día

2.- No siempre es posible que todos coincidan en el estimador, para eso hay diferentes tiradas y cada uno va explicando su razonamiento pero en un momento dado (tras 3 o 4 rondas) es el Scum Master el que termina preguntando: ¿te importa aceptar esta estimación? tomando como resultado el valor más votado. Hasta ahora no me he encontrado a nadie que diga: no, creo que yo tengo razón y vosotros no tenéis en cuenta esto y esto.


3.- Evitar que el dueño de producto y el equipo se centre en detalles. La última vez nuestro dueño de producto hablaba incluso ya del interfaz gráfico de usuario, en mi opinión esto deberá ser discutido cuando se planifique el sprint y aquí solo hablar de funcionalidad. El equipo también termina hablando de si usar un API, un lenguaje , etc y siempre les intento centrar en que valoren la funcionalidad y complejidad.

La siguiente reunión donde planificamos el sprint y ya no estimamos en puntos de historia sino en horas ideales ya no usamos planning poker, normalmente no nos hace falta a ese nivel y suele agilizar la planificación, de otra forma creo que serían demasiadas horas discutiendo sobre si una tarea tiene 2 o 3 horas ideales.

Me gustaría saber vuestras experiencias: ¿usáis planning poker en estimación del producto y también en la estimación de cada sprint? ¿cómo lográis que haya convergencia?

|

1 Comments


Nosotros tuvimos dificultades estimando en Story Points. Lo nuestro no es un proyecto, sinó un producto, y la siguiente vez que nos sentábamos a estimar había más historias nuevas que antiguas. Como consecuencia perdíamos la noción de la "unidad" y la discusión acababa siendo sobre la unidad en vez de sobre la funcionalidad.

Desde que estimamos en días ideales ya no tenemos ese problema. Me da pena porque no nos permitirá medir nuestra mejora (podemos esperar que nuestras estimaciones vayan bajando conforme vayamos mejorando nuestro rendimiento), pero que se le va a hacer.

Quizás cuando tengamos el PBL un poco más estable intentaremos SP de nuevo.

Publicar un comentario en la entrada