(Si no has leído Estimación Agile para dummies Parte I, te recomiendo que le eches un ojo para entrar en contexto)
La guía Scrum no trata la estimación, habla de estimar, pero no de cómo hacerlo. Existen numerosas y muy válidas formas de estimación que se adaptan muy bien a Scrum y a Agile. Y hay mucha documentación y bibliografía sobre cómo estimar que marcan unas directrices o pautas de buenas prácticas. Entre las cuales yo te recomiendo el libro
de Mike Cohn Agile Estimating & Planning, para mí un must have.
La fórmula más extendida, hoy por hoy para estimar, es mediante Planning Poker utilizando puntos de historia. A continuación, hablaremos de lo que es la comparación y cómo estimar con Planning Poker.
Estimación comparativa
A diferencia de lo que se suele pensar esta forma de estimar no pondera la complejidad y esfuerzo de ejecutar una tarea en sí misma; sino que compara la complejidad, el esfuerzo y la incertidumbre de una tarea con respecto a otra cuyo tamaño ya es conocido. A esto lo llamamos estimación relativa.
Cómo ya te habrás dado cuenta es muy importante, y en ocasiones no es sencillo, encontrar esa tarea, historia de usuario que se convierta en la referencia contra la cual comparar el resto del Backlog. Durante el primer Sprint de un equipo recién formado, no tendréis nada contra lo que comparar, pero no te preocupes al final del Sprint tendrás a buen seguro un puñado de historias candidatas.
De hecho no tiene por qué ser una única historia, podemos comparar las historias a estimar con un set de historias ya estimadas a fin de ser más precisos pero sobre todo evitar problemas como la inflación.
¿Inflación? ¿voy a pagar mas por mi hipoteca?
La inflación es el fenómeno por el cuál, el equipo progresivamente aumenta sus estimaciones, dando lugar a gráficas de velocidad alteradas que no responden con el rendimiento real del equipo. Suele darse por varios factores con los que el Scrum Master tiene que lidiar:
- No utilizar un elemento abstracto como los puntos de historia (ver artículo ¿Por qué deberías estimar en puntos de historia?) puede distraer la atención de cuál es el sentido de la estimación y no ayuda a evitar la inflación.
- Malinterpretar las métricas del equipo y en especial la de velocidad. Una mala interpretación de la velocidad por parte de personas ajenas al equipo puede hacer que el equipo infle las estimaciones para aumentar su velocidad.
Si queréis saber más sobre la inflación, podéis consultar el siguiente artículo de Mike Cohn.
Una vez definida la referencia de estimación ya se puede proceder con el proceso de estimar. En Scrum las estimaciones se llevan a cabo dentro del Sprint en las sesiones de refinamiento y en las ceremonias de Sprint Planning. Y es que aquí es donde hay otro cambio sustancial con respecto al modo en el que se viene estimando hasta ahora de manera tradicional. En Scrum se analiza (refina) y estima lo más tarde posible antes de ejecutar la tarea. Es decir, se sigue la filosofía Just-in-time de LEAN con el principio “just enough, just in time” (solo lo necesario y en el momento preciso).
¿Has oído hablar del Planning Poker?
¿Jugar al Poker en la oficina?
Como comentaba al inicio del post, la técnica más extendida para estimar es mediante Planning Poker, con Puntos de Historia. Para saber más acerca de los puntos de historia puedes consultar: ¿Que son los puntos de historia? ¿Por qué deberías estimar en Puntos de Historia?.
Con esta técnica el equipo en su conjunto “pesa” las historias, en Puntos de historia, mediante cartas con valores basados en la serie de Fibonacci. Típicamente se utilizan los siguientes valores: 0, 0,5, 1, 3, 5, 8, 13, 20, 40 y 100.
En el Planning Poker, el equipo tras leer y discutir acerca de la Historia de usuario asigna valores en Puntos de Historia con ayuda de las cartas de la baraja. Una vez todos tengan elegida una carta de la baraja se ponen en común y se discute acerca del resultado. En muy importante conocer las opiniones de los compañeros con estimaciones mas discrepantes para conocer todas las impresiones. Los procesos de voto y de discusión sobre lo votado, deben continuar hasta que se llegue a un acuerdo. Durante el proceso, gracias a las conversaciones mantenidas acerca de la historia, se logra un entendimiento más profundo de la historia de usuario a estimar y se tienen en cuenta todas las opiniones.
Como ves, a diferencia de como se venía estimando tradicionalmente es el equipo que va a ejecutar la tarea quien estima y justo antes de empezar el Sprint donde tiene planificado desarrollarla.
En resumen …
¿Qué ventajas tiene estimar de esta forma?
- Al estimarlo el equipo:
- Se logra un conocimiento mas profundo de la historia de usuario.
- Las estimaciones son más cercanas a la realidad, lo que permite ser más predecibles.
- Se tienen en cuenta todas las opiniones de los participantes del equipo. Generando inclusión y compromiso con lo acordado.
- Al hacerse mediante Puntos de Historia es muy simple adaptar el Sprint Backlog a la capacidad del equipo.
- Al realizarse justo antes de desarrollarse la historia:
- Se mitiga en parte el riesgo de que la historia de usuario cambie desde su inclusión al Backlog, evitando retrabajo.
- Se adapta de forma óptima en un ambiente de requisitos cambiantes donde no están claros los requisitos.
Continuará …
En siguiente post veremos un caso práctico para que puedas hacerte una idea de cómo estiman los equipos en Scrum. Let’s play (Planning) Poker. Caso práctico de Estimación Ágil
