08 Abr Estimaciones relativas con planning poker

El objetivo de este blog es enseñarle a nuevos equipos de Scrum a realizar estimaciones relativas con Planning Poker a través de un sencillo ejercicio que vengo usando con decenas de equipos desde hace años.

PASOS A SEGUIR

Seleccionar el criterio por el que se van a comparar estos animales: peso, tamaño, fuerza, velocidad, etc. En el ejemplo estimaremos por peso.

Descargarse la app móvil “Scrum Poker” de este link o una app similar. Si no pueden (no tienen acceso a Internet o no tienen espacio en el móvil) pueden estimar con papeles, los dedos, etc.

Se recomienda usar los valores 1, 2, 3, 5, 8, 13 y 20 de la escala de Fibonacci modificada.

Armar equipos de 5 personas. Cada equipo busca su pivote (el animal más liviano), le asigna 1 punto y compara los los demás animales con este.

Hacer una tabla de 7 x 2 con los siguientes valores:

PRIMERA RONDA

En este caso está claro que el animal más liviano (1 punto de historia) es la Ardilla.

Un pivote “1” en desarrollo de software podría ser crear un reporte bien básico, por ejemplo: “Consultar alumno por nombre”. Quizás una historia más compleja (3 puntos) podría ser: “Consultar las notas del alumno ordenadas por mes”.

Cada equipo debe llegar al consenso sobre su pivote y escribirlo en la tabla de la siguiente forma:

SEGUNDA RONDA

El equipo comienza a estimar el peso relativo del resto de los animales en comparación con la Ardilla. El razonamiento debería ser: ¿cuántas Ardillas pesa un Elefante? ¿O cuántos reportes básicos pesan uno complejo?

Supongamos que cuatro personas del equipo eligen 20 puntos pero una de ellas dice que es 13. Esa persona deberá justificar su estimación y “tratar de convencer” al resto. Decimos que los “extremos hablan”.

En un equipo de desarrollo de Scrum (recordar que no estiman ni el Scrum Master ni el Product Owner) van a discutir los programadores, testers, analistas, ux, y cada uno dará su punto de vista desde su experiencia y expertise. Una persona podrá decir que la historia X es compleja y estimarla en 20 puntos porque hay que desarrollar una nueva API, mientras otro desarrollador podrá decir que para él son 13 puntos ya que esa API ya se desarrolló en el sprint anterior y hay que reusarla. Lo mismo con los testers y funcionales, que agregarán su punto de vista de calidad y documentación. También en el equipo hay gente con mucha experiencia técnica y que hará las cosas más rápidas que alguien nuevo, por eso es bueno siempre pensar en estimaciones promedio, ya que no siempre el trabajo lo va a hacer la persona más rápida ni la más lenta. 

Recordar que no hay estimaciones buenas o malas, son disparadores de conversaciones para llegar a un consenso. Si luego de 3 rondas no se puede llegar al consenso, recomiendo quedarse con la estimación de la mayoría para hacerlo rápido (hay equipos que usan timeboxes, por ejemplo 3 minutos para estimar cada historia y llegar al consenso).

Algunas personas dirán que necesito 1000 ardillas para alcanzar el peso del elefante, no importa, no estamos buscando pesos absolutos en kilogramos sino estimando incertidumbre, complejidad y el esfuerzo que me demandará desarrollar una historia de usuario. 

Recordar que todos estiman al mismo tiempo para no sesgar la opinión del compañero. Cuantas más discusiones haya, mejor.

TERCERA RONDA

 

En este caso se estima el peso del Gorila, ya no sólo en proporción a la Ardilla (pivote) sino también al Elefante (triangulación).

Cuantas más estimaciones tengamos es mejor ya que me sirven para irlas comparando y pivoteando entre sí. 

En este caso, no solo me pregunto cuántas Ardillas pesa un Gorila, también sé que si al Elefante le puse el valor 20 y el Gorila es más liviano, entonces debería elegir un valor menor, 13 u 8 quizás.

Y así sucesivamente, se sigue estimando, un animal por ronda hasta completar la tabla.

Tener en cuenta que los valores se pueden repetir ya voy a tener muchas más historias que valores en la escala. Esto significa que el Oso puede tener el mismo valor relativo que el Gorila, por ejemplo: 13 puntos.

Como 20 puntos es mi tope, si le puse 20 a un Hipopótamo y luego 20 al Elefante, esto puede ser algo inconsistente. En la práctica lo que hago es, si el Elefante sé que pesa 40 entonces lo divido en un Hipopótamo (20 puntos) y un Rinoceronte (20 puntos).

La tabla final podría ser similar a la siguiente:

Al final del ejercicio, revisar estas tablas entre equipos, voy a tener estimaciones distintas y está bien que así suceda. Recordar que estas estimaciones se desarrollan intra pero no inter-equipo y no debería comparar su desempeño por la cantidad de puntos de historia que entregan por sprint sino por el valor solicitado por el Product Owner y entregado por el equipo.

CONCLUSIONES

• Los equipos de desarrollo de Scrum estiman distinto y por eso no se deben comparar sus valores ya que 20 puntos para uno es diferente que para otro.
• Un equipo debe compararse a sí mismo, buscar la mejora continua y entregar más valor para el negocio, iteración tras iteración.
• Que dos animales / historias de usuario tengan la misma estimación no significa que tengan el mismo peso en Kg o que demandarán exactamente el mismo esfuerzo para desarrollarse. Recordar que son estimaciones relativas y no absolutas.
• Recomiendo usar historias pequeñas, en promedio de 5 u 8 puntos. Si sé que una historia es mayor a 20 puntos, reducir su complejidad e incertidumbre mediante slicing o división en subhistorias. Si “Pagar con tarjeta” es demasiado grande entonces me conviene dividirla en dos historias, por ejemplo “Pagar con débito” y “Pagar con crédito”.
• Finalmente, sugiero involucrar a todo el equipo de desarrollo en las estimaciones, generar un ambiente de confianza que invite al debate de ideas y conversaciones y hacerlo rápido.