Puntos de historia sin teatro: cómo se ve lo bueno frente a lo malo
Pocas prácticas de Scrum se distorsionan tan rápido como los puntos de historia. Empiezan como una forma rápida de que un equipo de desarrolladores compare el tamaño relativo del trabajo y terminan como un marcador de productividad que alguien ajeno al equipo lee como una cotización bursátil. La Guía de Scrum no menciona en absoluto los puntos de historia —la estimación se deja al equipo—, y aun así muchas organizaciones tratan el número como el fin del ejercicio. Cuando eso ocurre, aparece el teatro: horas de debate, estimaciones infladas y un gráfico de velocidad que no mide nada real. La técnica está bien. El modo de usarla suele ser el problema.
Para qué sirven realmente los puntos
Un punto de historia es una medida relativa de esfuerzo, complejidad e incertidumbre, no una unidad de tiempo. Todo el valor de la estimación relativa es que las personas estiman mal al decir «esto tomará 6,5 horas», pero bastante bien al decir «esto es como el doble de grande que aquello». Los desarrolladores estiman juntos para que el pronóstico refleje un entendimiento compartido y para que la conversación saque a la luz la complejidad oculta antes de empezar. El número es un subproducto. La conversación es lo esencial. En el 2021 mayormente remoto, esa conversación se volvió más deliberada, y los equipos que la protegieron estimaron mejor que quienes redujeron la planificación a hacer clic en un número dentro de una herramienta.
Cómo se ve lo bueno
Los desarrolladores son dueños de las estimaciones; nadie de fuera del equipo las anula ni fija una «velocidad objetivo».
Estimar enciende una breve discusión que expone incógnitas, dependencias y criterios de aceptación faltantes.
El equipo usa la velocidad para pronosticar cuánto incorporar a un Sprint: una ayuda de planificación, no una nota de desempeño.
Los puntos son relativos y estables; el equipo compara el trabajo nuevo con historias de referencia que todos recuerdan.
Cuando la incertidumbre es alta, el equipo divide el elemento o hace un spike en vez de adivinar un número mayor.
Cómo se ve lo malo
La gerencia rastrea la velocidad como métrica de productividad y pregunta por qué «bajó», así que el equipo infla los puntos en silencio.
La estimación se vuelve una larga negociación sobre si algo es un 3 o un 5, sin ganar ningún entendimiento nuevo.
Los puntos se convierten calladamente en horas, frustrando todo el propósito de estimar de forma relativa.
Se compara la velocidad entre equipos, como si un punto significara lo mismo de un grupo a otro: nunca lo es.
El trabajo arrastrado e inconcluso se reporta como «terminado» para proteger el número, ocultando el estado real del Sprint.
Quitar el teatro
Si la estimación en su equipo se ha convertido en actuación, unos pocos movimientos deliberados suelen arreglarlo.
Mantenga la velocidad dentro del equipo. Deje de reportarla hacia arriba como una nota. Reporte resultados —incrementos funcionales y lo entregado—, no el número interno de pronóstico.
Acote el tiempo de la estimación. Si se debaten dos valores por más de un minuto o dos, elija el mayor y siga. La discusión ya le dio su valor.
Ánclese en historias de referencia. Acuerden un par de elementos pasados bien entendidos como su 3 y su 8, y estimen todo en relación con ellos.
Trate las sorpresas como señales. Cuando una estimación parece imposible, eso es información: la historia es demasiado grande o vaga. Divídala antes de comprometerse.
La prueba honesta de una estimación sana es simple: ¿confía el equipo en su propio pronóstico y le ayuda ese pronóstico a comprometerse con una Meta de Sprint realista? Si los puntos ayudan al equipo a planificar y mejorar, están funcionando. Si se han vuelto un número que la gente defiende, actúa o compara entre equipos, la técnica fue secuestrada, y ninguna estimación más fina arreglará un problema de confianza.
Si la estimación en sus equipos ha derivado en teatro y quiere recuperarla como una verdadera herramienta de planificación, la asesoría en ejecución de programas y proyectos de XNM puede ayudar a sus Equipos Scrum a estimar para informar en lugar de para actuar.