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?

|

Hoy hemos comenzado un nuevo proyecto y vamos a seguir usando SCRUM. Aprovecho este comienzo para seguir hablando de estimación ágil y, durante los siguientes posts, ir compartiendo los pasos que vamos siguiendo hasta terminar toda la funcionalidad.

El primer paso fue obtener la funcionalidad usando historias de usuario y el dueño de producto ya las tenía priorizadas, así que ayer mismo se convocó al equipo de desarrollo y al dueño del producto a la reunión de planificación de todo el proyecto que ha transcurrido de la siguiente forma:

1.- El dueño de producto ha dado una visión global de lo que será todo el proyecto para que todo el equipo conociera el contexto.

2.- Por orden de prioridad ha ido leyendo cada una de las historias de usuario

3.- El equipo realiza preguntas de alto nivel, no hay que centrarse en estos momentos en pensar si una llamada se realizará usando AJAX, si se utilizará un API u otra.

4.- El equipo daba una estimación



Se supone que al final de esta reunión se iba a obtener todas las historias de usuario estimadas y las que iban a ser desarrolladas por cada sprint, esto segundo no se ha logrado. Como el equipo era nuevo no se conocía su velocidad (ej. 30 puntos de historia por iteración) hemos optado por hacer un sprint 1 y obtener esta velocidad, a partir de ahí se obtendrá un plan completo.

La pregunta ahora es: si no tenemos la gran suerte de poder probar y obtener datos del primer sprint ¿que hago?. Las posibilidades son varias: podemos usar una velocidad previa de otros proyectos, otra opción es empezar a dividir la historia de usuario ya en tareas y estimarlas en horas ideales, el equipo decide hasta donde puede llegar a implementar y esa sería la velocidad inicial que tomaríamos, por ejemplo, si el equipo dice "en el primer sprint nos comprometemos a la funcionalidad A,B,C y D" sumamos los puntos de historia y esa será nuestra velocidad. Como siempre, en el futuro veremos que va ocurriendo y re-estimaremos.

Como podéis leer, en el punto 4 el equipo estimaba usando puntos de historia, ¿cómo hemos estimado? Se suele recurrir siempre a una persona "experta" y se le pregunta pero todos estamos de acuerdo en que debe estimar aquel que va a realizar el trabajo, una técnica muy buena y ágil es planning poker, estos son los pasos a seguir:

1.- Cada participante tiene un juego de cartas con un estimador escrito en cada una de ellas
2.- Cliente/Product owner lee una historia y se discute brevemente
3.- Cada participante escoge una carta
4.- Se vuelven las cartas a la vez
5.- Se discuten diferencias
6.- Se re-estima hasta que exista convergencia


La verdad es que la estimación ha ido muy bien y mañana planificamos el primer sprint.

|