Estimación ágil: la guía completa
Una guía práctica sobre la estimación ágil: historias de usuario, «planning poker», puntos de historia, velocidad y las técnicas que resultan útiles cuando una historia resulta ser más amplia de lo que parecía.
El «Planning Poker» es una técnica ágil de estimación basada en el consenso: los equipos votan de forma privada, revelan todas las cartas a la vez y debaten sobre la dispersión de los resultados hasta que las estimaciones convergen.
Cómo llevar a cabo una sesión de «planning poker» que ofrezca estimaciones útiles sin alargarse en exceso: preparación, la ronda de cuatro fases, elección de una baraja y establecimiento estricto de límites de tiempo.
Los puntos de historia miden el esfuerzo relativo, la complejidad y la incertidumbre del trabajo, no las horas. Cómo determinar el tamaño en comparación con una historia de referencia, y las dudas que suelen plantear dificultades a los equipos.
Los puntos de historia aumentan de 1, 2, 3, 5, 8 y 13 porque las diferencias cada vez mayores reflejan la incertidumbre: la escala deja de pretender que se pueda distinguir un 13 de un 14. He aquí por qué las diferencias son lo importante.
Los puntos de historia miden el esfuerzo relativo; las horas miden la duración: son ejes distintos. Si elabora una tabla de conversión de puntos a horas, habrá vuelto, sin darse cuenta, a estimar el tiempo.
La velocidad es la media de los puntos de historia que un equipo completa por sprint. Para qué sirve, por qué deja de funcionar en cuanto se convierte en un objetivo y cómo garantizar su fiabilidad.
A las personas les cuesta estimar «cuánto tiempo llevará esto», pero se les da bien comparar «si esto es mayor que aquello». La estimación relativa se basa en lo segundo, y por eso funcionan los puntos de historia.
Las estimaciones iniciales presentan un amplio margen de variación porque se desconoce el alcance del trabajo, no porque su equipo no sea capaz de realizar estimaciones adecuadas. Qué significa el «cono de incertidumbre» y cómo reducirlo —en lugar de ampliarlo—.
Las epopeyas, las historias y las tareas son tres niveles con tres funciones. En qué consiste cada uno, cuál de ellos genera puntos de historia y por qué centrarse en el nivel equivocado hace que la velocidad pierda todo su sentido.
Comparativa de técnicas de estimación ágil: «planning poker», el método de las camisetas, los «buckets», la votación por puntos, la estimación por afinidad y la estimación «mágica», así como el modo de fallo que cada una de ellas encierra.
Los errores más habituales en las sesiones de Planning Poker —el cálculo de la media de las cartas, las estimaciones en horas, el uso indebido de la «velocidad» y la inflación de los puntos de historia— y cómo solucionarlos.
Los criterios de aceptación constituyen la prueba de aprobación o rechazo de una historia, que se redacta antes de comenzar el trabajo: los formatos que funcionan, ejemplos concretos y en qué se diferencian de la definición de «terminado».
La definición de «terminado» consiste en una lista de comprobación para todo el equipo que cada historia debe superar antes de su entrega. Un ejemplo de esta definición, quién es el responsable de la misma y en qué se diferencia de los criterios de aceptación.
La definición de «listo» es la lista de comprobación que indica que una historia está lista para incluirse en un sprint. Qué aspectos abarca una lista útil, por qué se ignoran la mayoría de ellas y cuál es la versión que realmente supone un obstáculo.
Una historia que no se puede evaluar suele ser una que aún no se puede publicar. Cómo saber cuándo dividirla, cuáles son las líneas de corte que dan lugar a fragmentos listos para su publicación y cuáles solo lo simulan.
SPIDR consiste en cinco métodos fiables para dividir una historia de usuario: spike, path, interface, data y rules. Cada línea de división, cuándo funciona y cuándo da lugar a una división errónea.
Las divisiones verticales aportan valor; las divisiones horizontales aportan promesas. Por qué la división por capas tecnológicas retrasa la obtención de valor, y cómo dividir por resultados para el usuario para que se entregue algo en cada sprint.
Una historia de usuario es una promesa de valor breve y redactada en un lenguaje sencillo. El formato «función-objetivo-beneficio», las tres «C», la lista de verificación INVEST y los casos en los que las historias no son la herramienta adecuada.
Dieciséis ejemplos de historias de usuario sobre autenticación, comercio electrónico, dispositivos móviles, API y errores; cada uno de ellos viene acompañado de comentarios, y las versiones incorrectas aparecen junto a sus versiones revisadas para que se pueda apreciar la diferencia.
La plantilla clásica de una historia de usuario con una ficha de «copiar y pegar», las variantes que conviene conocer y un ejemplo práctico que se ha desarrollado desde la plantilla hasta los criterios de aceptación y la estimación.