Caso práctico de estimación en Scrum con puntos de Historia y Planning Poker

En este artículo pretendo ejemplificar un caso práctico de estimación ágil de cara a arrojar luz sobre el proceso de estimación basado en Planning Poker con Puntos de Historia.

Este post supone el fin de la serie de Estimación Agile para dummies que empecé el mes pasado. Si no los has visto todavía dejo aquí los enlaces:

Si bien este post es fácil de seguir yo te recomiendo que los revises de cara a tener un mejor contexto sobre cómo llevar a cabo una estimación ágil.

El contexto …

Para llevar a cabo el caso práctico necesitamos una historia de usuario dentro de un contexto ágil, con lo que asumamos que se nos ha encomendado … ¡¡un producto espacial!!

 “La empresa SpaceXYZ en su programa “Go Mars” plantea llevar a marte provisiones y tripulación en 2024, a bordo de la lanzadera Starship Trooper I. Dentro de este programa, bajo la dirección de explotación y marketing se ha lanzado el desarrollo de un producto para gestionar todo lo relacionado con la venta de plazas de vuelo, admisión de nuevos clientes y gestión de equipajes y carga de la nave. Uno de los aspectos más controvertidos del programa, es que en cada vuelo a Marte se reservarán un número limitado de plazas para voluntarios. Estos voluntarios a cambio de trabajar de forma altruista podrán formar parte de la experiencia de viajar al planeta rojo.”

A continuación, tenemos la Historia a estimar (izquierda) y la Historia que utilizaremos de referencia (derecha).

Historia a estimar (izquierda) – Historia de referencia (derecha)

Bien, ya tenemos qué estimar y con qué comparar. P ¿cómo estimamos? ¿cómo jugamos a Planning Poker?

¿Cómo aplicamos Planning Poker?

En el proceso de Planning Poker se reparte una baraja con valores en puntos de historia que siguen una progresión típicamente relacionada con la serie de Fibonacci. Los valores más habituales de estas barajas suelen ser 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100, “?” e infinito.

Baraja típica de Planning Poker

Una vez que todos los integrantes del equipo tienen una baraja, se lee en alto la historia, se discute sobre la complejidad y riesgos y se aclaran las posibles dudas que surjan con el Product Owner. Se recuerda, en el caso que sea necesario, la historia acordada como marco de referencia con la que se van a comparar las historias a estimar.

Tras una primera discusión entre el equipo, cuando haya quedado más o menos claro el qué es lo que hay que hacer, cada miembro elige una carta de la baraja, y una vez que todos hayan elegido su carta se ponen boca arriba. Se ha realizado la primera votación.

Resultado de la primera votación.

Bueno, analicemos que información nos arroja esta primera votación:

En primer lugar, tenemos dos miembros del equipo que estiman la Historia de Usuario en 3, hay otros tres miembros del equipo que consideran que pesa 5 y John Doe considera que son 13 los puntos de historia que debía pesar esta historia.

Rápidamente podemos atisbar que no tenemos consenso y, en particular John estima la tarea 4 veces más compleja que dos de sus compañeros. Ante este escenario, hay que interpretar que John ha podido ver algo que el resto de sus compañeros no han visto. Para averiguarlo hay que invitarle a que explique los motivos por los qué ve mucho más compleja la Historia de usuario que el resto de sus compañeros.

Estos son los argumentos que han llevado a John a estimar 13:

John: “Chicos creo que no estáis teniendo en cuenta que la misión es internacional y podrían inscribirse voluntarios de varios países. Esto implica que hay que tener en cuenta cargar los códigos postales de todos los países de los que se admiten candidatos y soportar además inscripciones en idiomas con caracteres chinos, japoneses, coreanos o cirílicos”

Tras la exposición de John, el equipo vuelve a discutir sobre las implicaciones que comenta John. Llegados a este punto varios miembros del equipo podrían incrementar su votación gracias a los motivos que ha expuesto John, incluso John podría reducir el peso de su votación si alguno de los contra-argumentos de sus compañeros le convencieran. Tras llegar a un entendimiento de la nueva complejidad y riesgo de la Historia se vuelve a votar.


Resultado de la segunda votación.

En esta segunda votación una buena parte del equipo ha sido consciente de que el desarrollo parece mas complejo de lo que en un inicio planteaba. Sin embargo, John sigue viéndola muy compleja y Jane la sigue viendo simple. Es más, Jane ve la Historia con una complejidad menor de la mitad de lo que estima John.

¿Qué debemos hacer? De nuevo hay que hacer aflorar las razones que generan esta discrepancia y para eso nada mejor que el hecho de que ambos expliquen que ha motivado dicha estimación.

John: “Ya os he comentado que no es tan fácil como pensáis”

Jane: “Bueno, si bien es necesario que se soporten varios tipos distintos de caracteres, esto no debería afectar demasiado ya que el framework sobre el que se va a apoyar el desarrollo, lo resuelve:”

Estos argumentos deben generar una nueva discusión en el equipo y una nueva votación hasta que se llegue a un acuerdo sobre cuál será la estimación asociada en la historia. En nuestro ejemplo, en la tercera votación tenemos:

¡Et voila! Ya tenemos consenso y valor de estimación para la historia: 8

Este es un devenir habitual en las estimaciones llevadas a cabo en Planning Poker. Los equipos menos maduros, o que lleven poco tiempo trabajando juntos, discreparan en un inicio más que los maduros.

En la realidad no suelen hacer falta más de tres iteraciones – votaciones, para converger en un valor de estimación. Suele ocurrir también, que aquellos que en una votación estiman muy alto una historia, en la siguiente votación suelen encontrarse en el caso contrario dando una estimación más baja del consenso.

Y recuerda, lo más importante es que, mediante estas discrepancias y discusiones, el equipo logra un mejor entendimiento y detalle de la tarea a abordar y genera complicidad y compromiso.

En resumen …

Una vez visto el ejemplo, vamos a resumir el proceso que se ha seguido en él para llevar a cabo la estimación.

PRE-REQUISITOS:

Antes de comenzar, necesitamos una (o varias si aplicamos triangulación) historia de referencia con la que comparar las historias a estimar y algo que estimar.

PASOS:

  1. Para empezar se lee la Historia de Usuario en alto y se discuten sus distintas interpretaciones hasta llegar a un acuerdo mínimo de entendimiento.
  2. Si es necesario, se lee la Historia de Usuario o tarea que se ha acordado de referencia.
  3. Una vez entendidas ambas se vota el “tamaño” de la Historia de Usuario.
  4. Si no hay consenso, se da la palabra a los miembros del equipo con estimaciones muy bajas o muy altas, quizás ellos hayan visto algo que al resto les haya pasado desapercibido.
  5. Se discute nuevamente con estos nuevos argumentos y se vota de nuevo.
  6. Y se sigue votando y discutiendo hasta consensuar un valor de estimación.

Preguntas frecuentes:

Si un equipo no termina poniéndose de acuerdo con la estimación, ¿Cómo acordamos un valor de estimación?

Si tras varias iteraciones este resultado se mantiene, y no existe forma de ponernos de acuerdo, se suele tomar la decisión de adoptar la estimación mayoritaria. Pero el valor en sí que acordemos es indiferente. Si han aflorado una buena cantidad de dudas y preguntas que han logrado un mejor entendimiento de la Historia, hemos llegado al objetivo de nuestra estimación. Y si nos equivocamos lo veremos al final del Sprint y aprenderemos de ello.

¿Qué pasa si alguien saca la carta de 0?

La carta de 0 implica que la tarea tiene un valor despreciable, es común que pueda salir y no tiene más importancia.

¿Qué pasa si alguien saca la carta de ∞?

¿Y ahora qué? La carta de infinito implica que la historia en sí no se puede abordar por el momento porque no se dispone de la información necesaria para poder estimarse. Es posible que esté recién recogida y por tanto tenga poco detalle, el Product Owner tiene que darle aún mas forma antes de ser “estimable”. Que sea estimable es uno de los aspectos más importantes a la hora de escribir una historia. Recuerda que las historias bien escritas deberían seguir el Acrónimo INVEST: independent, negotiable, valuable, estimable, short y testable. Si quieres saber mas sobre el acrónimo INVEST puedes visitar el post “Escribe mejor tus Historias de Usuario (INVEST)

¿Qué pasa si alguien saca la carta de Café?

Quien saca la carta de café es porque ya no puede con su vida (estimadora) y necesita gasolina, si tiene sentido en este momento, ¿por qué no hacemos un alto en el camino?