Story Points bajo fuego: ¿Siguen Siendo Relevantes en Agile?
Analicemos en detalle esta controversia y veamos si podemos darle sentido a todo esto.
Scrum Alliance afirma que los Story Points (Puntos de Historia) son «unidades relativas de estimación específicas del equipo utilizadas para estimar requerimientos» [1]. Se puede extraer mucha información de esta definición, así que discutamos sus dimensiones principales.
En primer lugar, los Story Points son específicos de cada equipo, por lo que su valor no es aplicable en otros equipos. El equipo de desarrollo estima el esfuerzo requerido para cada requerimiento, por lo que el nivel percibido de esfuerzo está influenciado por el tamaño del equipo, su experiencia, antecedentes y cuánto tiempo han estado trabajando juntos. Es probable que otro equipo tenga una perspectiva distinta y, por lo tanto, un valor estimado diferente para el mismo trabajo.
En segundo lugar, establece que los Story Points son una forma de dimensionar los requerimientos en relación con otros. Por lo tanto, se debe asignar un valor arbitrario a uno o pocos requerimientos para comparar y medir el resto contra él, independientemente de cómo se implementen los Story Points (o cualquier otra forma de estimación relativa). En la práctica, los equipos realizan una sesión de planning poker, analizan los requerimientos juntos, los comparan con otros requerimientos conocidos y asignan un valor de Story Points basado en el esfuerzo relativo requerido.
Tercero, ¿para qué se usan? Gran parte de la conversación trata sobre eso. Ron Jeffries, uno de los fundadores de Extreme Programming (XP) y probablemente el padre de los Story Points, dijo que cuando comenzaron a usar los puntos, «solo usaron los puntos para decidir cuánto trabajo tomar en una iteración» [2]. Hoy en día pasa lo mismo. Los equipos utilizan estas estimaciones para decidir cuánto trabajo incluir en el próximo sprint (iteración) reflexionando sobre cuánto trabajo han podido completar históricamente. Esto permite al equipo establecer una meta realista dentro de los límites de su propia capacidad.
El argumento a favor de los Story Points: Una Medida de Velocity
Comencemos con el lado pro-Story Points. El argumento es que los Story Points son esenciales para medir el velocity. Al asignar puntos a las historias de usuario, los equipos pueden estimar cuánto trabajo pueden abordar en un sprint. Los usuarios registran los Story Points como ganados cuando completan cada historia de usuario. Es como ir al gimnasio y registrar el peso que puedes levantar cada vez. La próxima vez que vayas, ya sabes de lo que eres capaz.
Beneficios Clave de los Story Points:
- Colaboración del Equipo: La estimación con Story Points a menudo ocurre en una sesión de planning poker. Esto fomenta las discusiones en equipo, promueve la colaboración y asegura que todos estén en la misma página y tengan suficiente información sobre los requerimientos.
- Estimación Relativa: Los Story Points permiten a los equipos estimar los requerimientos comparando unos con otros, lo que facilita evaluar el esfuerzo evitando las trampas de las predicciones de tiempo.
- Predictibilidad: Después de completar algunos sprints, los equipos pueden rastrear su velocity (promedio de puntos completados por sprint) y estimar la capacidad futura. Esto ayuda en la planificación y gestión de las expectativas de las partes interesadas.
¿Por qué necesitamos estimar?
Ya sea que estés a favor o en contra de los Story Points, es importante entender por qué existen. La mayoría de los equipos persiguen un objetivo y enfrentan restricciones de tiempo, presupuesto, calidad y alcance, incluso en un entorno Agile. Si bien estas restricciones son flexibles, aún se necesita negociación y se deben gestionar las expectativas.
Estimar, ya sea usando Story Points o no, permite a los equipos volverse predecibles y planificar hacia un objetivo, lo que ayuda a establecer expectativas claras, identificar riesgos y facilitar la comunicación con las partes interesadas.
El caso contra los Story Points: Encontrando Alternativas
¿Has escuchado la frase «Story Points are trash» o la historia donde Ron Jeffries se disculpa por crearlos? Bueno, hay un movimiento creciente contra los Story Points. Los críticos argumentan que son una abstracción innecesaria que puede llevar a la fatiga de estimación, resultados inconsistentes y expectativas mal manejadas. Algunas organizaciones incluso han utilizado estas estimaciones para medir el rendimiento y comparar diferentes equipos.
Críticas Clave de los Story Points:
- Sobrecarga: El proceso de estimar Story Points puede consumir mucho tiempo, restando del trabajo de desarrollo real.
- Enfoque en los números: Los críticos, como los defensores de #NoEstimates, argumentan que los Story Points pueden cambiar el enfoque a completar puntos en lugar de entregar valor.
- Mal uso: Comparar equipos, usarlos como medidas de desempeño, fijar un objetivo, establecer un equivalente de tiempo, y otros son solo algunos ejemplos de cómo se sabe que los managers «utilizan como arma» los Story Points.
Voces influyentes como Woody Zuill y Neil Killic, defensores de #NoEstimates, argumentan que los equipos deberían enfocarse en entregar software valioso incrementalmente en lugar de enredarse en la estimación del esfuerzo. [4]
Entonces, tomando en cuenta los pros y los contras, ¿deberíamos eliminar las estimaciones por completo? ¿Cuáles son las alternativas para un equipo que quiere datos útiles para conocer sus capacidades y optimizar la entrega de valor?
Varios autores, así como algunas herramientas [5], promueven el uso de los siguientes datos en lugar de Story Points y los etiquetan como alternativas:
- Métricas basadas en Flujo: ¿Cuánto tiempo y dónde los elementos pasan tiempo en la línea de producción?
- Cycle Time
- Lead Time
- Time to Deploy
- Aging items
- Time to Review
- Inversión en Desarrollo: ¿En qué están invirtiendo más tiempo los equipos? ¿Nuevas características, mejoras o corrección de errores y resolución de problemas?
- Tamaño de Lote: Cuán grandes son los cambios incluidos en cada elemento.
- Tasa de Retorno: Número de elementos devueltos versus enviados para pruebas.
- Frecuencia de Implementación: Número de veces que una versión llega al entorno de producción por día, semana, etc.
A estas alturas, probablemente haya notado que estas no son alternativas a las estimaciones, sino datos complementarios que permiten a los equipos comprender cómo fluye el trabajo. Estos han demostrado ser valiosos para ver el panorama general, analizar problemas y ajustar si es necesario. Te recomiendo leer el artículo de dos partes de Sherley Brito sobre Gestión de Entrega Basada en Datos para una inmersión profunda en algunas de estas métricas.
Técnicas de estimación alternativas
Como se discutió anteriormente, la mayoría de los equipos necesitan estimar para planificar, establecer y gestionar expectativas, y facilitar la negociación con las partes interesadas. Si usted y su equipo necesitan estimaciones y desean disfrutar de los beneficios de estimar los requerimientos, como promover discusiones, fomentar la colaboración y gestionar expectativas, pero desean evitar las dificultades, vale la pena considerar alternativas. Aquí hay solo dos de ellas:
Horas Ideales:
Imagina un mundo sin interrupciones, distracciones u otro trabajo con el que lidiar. Eso es lo que las Horas Ideales intentan capturar: el tiempo estimado que tomaría una tarea en condiciones perfectas. Es más concreto y fácil de entender para todos. Sin embargo, puede confundirse con tiempo absoluto, creando presión y estrés. Es como pensar que puedes cocinar una comida en 30 minutos, porque eso dice la receta, sin considerar el tiempo invertido buscando ese ingrediente en la despensa (o incluso en el supermercado).
Tamaños de T-shirt: 
Piensa en los Tamaños de T-shirt como un familiar cercano de los Story Points. En lugar de usar números, usa tamaños como S, M, L y XL para expresar el tamaño relativo de los requerimientos. Son fáciles de entender y flexibles, lo que los hace perfectos para fomentar la colaboración y la discusión. Además, como sumar tamaños no es intuitivo, es menos probable que se utilicen mal como medida de rendimiento. Sin embargo, por la misma razón, pueden no ser tan útiles para comprender la capacidad del equipo.
Al explorar estas alternativas, puede encontrar un método que mantenga a su equipo alineado y motivado.
Liderando un Equipo Ágil: Con o sin Story Points
Ya sea que esté a favor o en contra de los Story Points, su objetivo debe ser entregar valor. Y hay mérito en las críticas. Las estimaciones no deben usarse para medir el rendimiento ni para decir que un equipo es lento en comparación con otros, ni los managers deben usar una «tabla de conversión» para microgestionar a los miembros del equipo.
Sin embargo, las métricas de flujo y de calidad no deberían ser considerados solo por los equipos que deciden alejarse de las estimaciones. Usarlas permite a los equipos ver el panorama general y leer la historia completa.
Entonces, ¿dónde nos deja eso? Ya sea que defiendas los Story Points o pienses que son malvados, la clave es encontrar lo que funciona mejor para tu equipo. Al usar alternativas, puedes aprovechar los beneficios de las estimaciones y hacer todo lo posible para evitar las dificultades. Complementa tu dashboard con métricas de flujo y de calidad, y otra información como la frecuencia de implementación, la tasa de retorno, etc.
En última instancia, el objetivo es entregar valor, fomentar la colaboración y mejorar continuamente. Diferentes equipos tienen distintas necesidades, y no existe un enfoque único para todos. Adapte e itere su enfoque para que coincida con las necesidades de su equipo y las de las partes interesadas, manteniendo la vista en el premio: entregar valor.
Fuentes