Durante años, los story points se han considerado una "mejor práctica" en el mundo ágil para estimar y planificar el trabajo en los equipos de desarrollo. Influenciados por libros populares y coaches bien intencionados, muchos equipos adoptaron esta técnica buscando una forma más efectiva de predecir cuándo se completarían las funcionalidades y de reportar el progreso a sus clientes y stakeholders.
Sin embargo, a medida que la agilidad madura y evoluciona, cada vez más voces expertas se atreven a cuestionar la utilidad real de los story points. Autores de referencia como Ron Jeffries, co-creador de Extreme Programming y los story points, ahora los considera un "maldito error". Otros firmantes del Manifiesto Ágil, como Martin Fowler o Ken Schwaber, también expresan sus dudas sobre las estimaciones y la obsesión por medir la velocidad.
Basándose en la experiencia de incontables equipos, reconocen que los story points a menudo no cumplen sus promesas y pueden incluso llevar a comportamientos disfuncionales que socavan los valores ágiles. Estimar el trabajo en puntos relativos consume mucho tiempo y esfuerzo, sin agregar valor directo para el cliente. Las supuestas ventajas para la planificación rara vez se materializan dado el entorno volátil y cargado de incertidumbre en el que operan los equipos de software.
Pero más allá de su cuestionable utilidad, el problema de fondo es que los story points reflejan una mentalidad de "comando y control" heredada de enfoques tradicionales como el Taylorismo. Ponen el foco en la eficiencia individual y la precisión de las estimaciones, en lugar de medir el valor generado y el aprendizaje. Llevan a comparaciones injustas entre equipos y a la tentación de "jugar con los números" para aparentar más velocidad.
En un contexto donde el cambio es la norma, seguir aferrados a la predictibilidad de los story points nos ancla al pasado. Necesitamos métricas que abracen la incertidumbre intrínseca del desarrollo de productos innovadores. Métricas que fomenten la colaboración, la experimentación y la entrega continua de valor.
Es hora de que los equipos ágiles se atrevan a soltar la "muleta" de los story points y adopten un enfoque sin estimaciones. Un enfoque empírico, basado en medir el flujo de trabajo terminado y ajustar continuamente las expectativas. Solo así lograremos organizaciones ágiles genuinas, capaces de surfear el cambio y generar resultados extraordinarios.
A continuación, exploraremos en detalle 5 razones para abandonar los story points y abrazar la agilidad sin desperdicios:
- Los story points no hablan en el idioma del cliente: Los story points son una abstracción que tiene sentido para el equipo de desarrollo, pero resultan crípticos e incomprensibles para los clientes y stakeholders. Decirle a un cliente que una funcionalidad es un "3" o un "5" en términos de story points no le proporciona ninguna información valiosa sobre cuándo podrá tener ese feature en sus manos o cuánto valor le aportará. En el contexto de una transformación ágil, donde buscamos involucrar al cliente y hacerlo parte del equipo, necesitamos métricas que sean transparentes, fácilmente interpretables por todos y centradas en lo que realmente le importa al cliente: cuándo se entregarán sus requerimientos priorizados y qué beneficios tangibles le traerán. Los story points, al ser una medida relativa, fallamos en "hablar el lenguaje" de nuestros clientes.
- Los story points pueden incentivar comportamientos incorrectos: Al ser los story points la base para medir la velocidad del equipo, se crea una presión implícita por "cumplir los puntos". Esto puede llevar a los equipos a inflar las estimaciones para aparentar que están haciendo más, o peor aún, a sacrificar la calidad con tal de terminar todas las historias comprometidas para el sprint. En lugar de fomentar la entrega incremental de valor, los story points pueden incentivar el "efecto estudiante", donde se deja todo para última hora. Así, los equipos caen en "mini-cascadas", concentrando el trabajo al final de la iteración, lo cual va en contra del principio ágil de mantener un ritmo sostenible y constante. Estos comportamientos tóxicos, motivados por cumplir con una métrica abstracta, alejan al equipo del verdadero objetivo: generar valor continuamente para el cliente.
- Las estimaciones en story points son inconsistentes: Incluso siguiendo prácticas recomendadas como la estimación relativa y el planning poker, las estimaciones en story points muestran una alta variabilidad en el tiempo real que toma completar las historias. No es raro ver historias de 2 puntos que toman más días que historias de 8 puntos. Esto se debe a que el desarrollo de software es una actividad compleja, con muchos factores impredecibles que afectan el esfuerzo necesario. La dificultad técnica, las dependencias, los cambios de contexto, e incluso el estado anímico de los desarrolladores pueden influir drásticamente en la duración de una tarea. Al observar la amplia dispersión entre los story points y el tiempo real de desarrollo, queda claro que los puntos no son un buen predictor del esfuerzo necesario, y por ende, no proveen una base confiable para proyectar fechas de entrega.
- Los story points no tienen en cuenta el contexto: Las estimaciones en story points se basan en suposiciones ideales que rara vez se cumplen. Se asume que el equipo estará 100% dedicado, que no surgirán interrupciones o imprevistos, y que las historias se podrán trabajar de manera continua hasta su fin. Pero la realidad es que durante un sprint ocurren muchas otras actividades que "roban" tiempo al equipo: reuniones, análisis de requerimientos, diseño de alto nivel, pruebas exploratorias, resolución de defectos, atención a problemas de producción, etc. Ninguna de estas tareas suele estimarse en story points. Además, conforme avanza el proyecto, van surgiendo nuevos riesgos, restricciones e impedimentos que alteran radicalmente la capacidad del equipo. Los story points, al ser estáticos, no capturan estos cambios en el contexto. Como resultado, las proyecciones basadas en story points se tornan cada vez más irreales a medida que pasa el tiempo.
- Existen enfoques alternativos centrados en medir el flujo: En lugar de invertir tiempo en estimar el esfuerzo futuro en una unidad abstracta, podemos optar por medir el trabajo real terminado y utilizar esos datos para proyectar los próximos entregables. Métricas como el Tiempo de Ciclo (cuánto tarda una historia desde que se inicia hasta que se entrega) y la Antigüedad del Trabajo en Progreso (cuántos días lleva una tarea desde que se empezó), nos dan una visión más realista y actualizada de la capacidad del equipo. Con estas métricas podemos hacer pronósticos probabilísticos, indicando por ejemplo que "basados en los últimos 3 meses, el 85% de las historias se entregan en hasta 10 días". Esto permite negociar los acuerdos de niveles de servicio con los clientes de una forma transparente. A su vez, el monitoreo del flujo fomenta los comportamientos correctos, como priorizar, descomponer las historias grandes, limitar el trabajo en proceso, balancear las especialidades y colaborar para terminar lo ya iniciado, en lugar de comenzar nuevas tareas. Estos enfoques alternativos no buscan una precisión ilusoria, sino gestionar la incertidumbre intrínseca al desarrollo de software de una forma empírica y orientada a la generación de valor.
¿De qué formas un equipo podria iniciar la transición y dejar el uso de estimación basada en puntos de historia?
Para que un equipo inicie la transición y deje atrás la estimación basada en puntos de historia, puede seguir los siguientes pasos:
- Acordar como equipo adoptar un enfoque sin estimaciones: El primer paso es generar una discusión abierta dentro del equipo sobre los problemas e inconvenientes que han experimentado al usar story points. Es importante que todos expresen sus perspectivas y que se llegue a un consenso sobre la necesidad de explorar alternativas. El equipo debe estar alineado y comprometido con la idea de abandonar gradualmente las estimaciones e iniciar una transición hacia un enfoque basado en medir el flujo de trabajo.
- Educarse en métricas alternativas centradas en el flujo: Para reemplazar los story points, el equipo necesita familiarizarse con nuevas métricas que le permitan entender y pronosticar su capacidad de entrega. Algunos ejemplos son:
Tiempo de Ciclo: ¿cuánto tiempo tarda una historia desde que se inicia hasta que se entrega?
Tiempo de Espera: ¿cuánto tiempo pasa una historia esperando en cada etapa del flujo de trabajo?
Antigüedad del Trabajo en Progreso: ¿cuántos días lleva una tarea desde que se empezó?
Throughput: ¿cuántas historias se completan por unidad de tiempo (iteración/semana/mes)? El equipo puede organizar sesiones de aprendizaje para profundizar en estos conceptos y analizar cómo aplicarlos en su contexto.
- Visualizar y medir el flujo de trabajo: Para adoptar las nuevas métricas, el equipo necesita hacer visible su flujo de trabajo. Puede comenzar mapeando las etapas por las que pasa una historia desde su concepción hasta su entrega, y plasmarlo en un tablero físico o digital. Luego, debe instrumentar la medición de los tiempos en cada etapa, registrando las fechas de inicio, fin y tiempo de espera. Para esto puede utilizar herramientas digitales como Jira, Trello o Azure DevOps, que permiten capturar estos datos de manera automatizada. El equipo debe acordar la granularidad y frecuencia de las mediciones, buscando un equilibrio entre la precisión y la carga administrativa.
- Establecer líneas base y pronósticos probabilísticos: Con los datos de flujo recolectados durante un período significativo (al menos 3-6 meses), el equipo puede comenzar a establecer sus líneas base. Por ejemplo, puede calcular el Tiempo de Ciclo promedio o el percentil 85 de su distribución. A partir de estas líneas base, el equipo puede realizar pronósticos probabilísticos sobre cuándo se completarán las historias priorizadas. Por ejemplo: "dada nuestra historia, podemos pronosticar con un 85% de confianza que esta historia estará terminada en hasta 15 días". Estos pronósticos se basan en evidencia empírica y se actualizan continuamente a medida que el equipo madura y mejora su desempeño.
- Fomentar la entrega y retroalimentación continuas: Un enfoque sin estimaciones requiere un cambio de mentalidad en el equipo. En lugar de orientarse a cumplir compromisos basados en story points, el equipo debe centrarse en entregar valor de manera continua y obtener retroalimentación frecuente del cliente. Esto implica prácticas como la integración y entrega continuas (CI/CD), el despliegue en pequeños lotes, las revisiones periódicas con usuarios y la priorización colaborativa del backlog. El equipo debe adoptar una cultura de experimentación y aprendizaje, donde se valora más el conocimiento generado que la precisión de las estimaciones.
- Negociar acuerdos de nivel de servicio (SLAs) con el cliente: En lugar de comprometerse a fechas fijas basadas en story points, el equipo puede negociar SLAs con sus clientes basados en sus métricas de flujo. Por ejemplo, puede acordar que el 85% de las historias se entregarán en hasta X días. Estos SLAs son dinámicos y se ajustan continuamente según el desempeño real del equipo. Brindan una base objetiva para manejar las expectativas y permiten una mayor transparencia y confianza con los interesados.
- Mejora continua del flujo de trabajo: Por último, el equipo debe adoptar una mentalidad de mejora continua, utilizando sus métricas de flujo para identificar cuellos de botella, ineficiencias y oportunidades de optimización en su proceso. Prácticas como el análisis de flujo de valor, la teoría de las restricciones y el análisis de causa raíz pueden ayudar al equipo a encontrar formas de acortar sus tiempos de ciclo, reducir el trabajo en progreso y aumentar su capacidad de entrega. La clave es entender que el camino hacia la agilidad sin estimaciones es un proceso de aprendizaje iterativo, donde el equipo continuamente experimenta, mide, aprende y adapta su enfoque.