Los story points no sirven: mide las colas

• Los story points son completamente poco confiables, generan confusión y obligan a recordar constantemente a las partes interesadas qué significan
  • Los valores bajos de puntos son más precisos, pero los valores altos asumen una mayor variabilidad y representan rangos, por lo que no se pueden sumar con precisión
  • Los story points no representan tiempo, pero al combinarse con métricas de velocidad terminan significando tiempo en la práctica, lo que desde el inicio arruina el acto de sumar números y rangos
• Estimar software es difícil, y el resultado del proceso por lo general no es útil en comparación con el esfuerzo invertido
• Los equipos pequeños con pocas interrupciones parecen estimar con precisión, por lo que en la mayoría de los casos dan la impresión de que lo que hacen está funcionando bien
• Cuando la capacidad se utiliza por completo, la variabilidad de todo el trabajo se dispara, afectando drásticamente todas las estimaciones y cronogramas
• Las colas medidas resuelven los problemas de estimación de corto y largo plazo, manejan naturalmente los cambios de alcance y ofrecen una práctica mucho más valiosa para equipos grandes al eliminar la incertidumbre
• Las colas medidas ofrecen un indicador adelantado que predice problemas 20 veces más rápido que las métricas de velocidad o de cycle time

¿Qué son los story points?

• Según Atlassian, los story points son una unidad para expresar una estimación del esfuerzo total necesario para implementar por completo un elemento del product backlog u otro trabajo
• Los puntos representan complejidad, volumen de trabajo, riesgo o incertidumbre, y la cantidad de trabajo
• Medir la complejidad es algo relativo, por lo que distintos equipos pueden evaluar el mismo trabajo de manera diferente
• Debido a la naturaleza relativa de los puntos, compararlos entre equipos no tiene sentido, y ese es un problema frecuente a nivel de gestión

Variabilidad inherente

• Los story points se basan en la secuencia de Fibonacci, por lo que los valores más altos representan una mayor variabilidad
• Sumar valores de puntos con alta variabilidad no tiene sentido, y sumar puntos en métricas de velocidad es incorrecto
• Según la ley de Goodhart, cuando una medición se convierte en objetivo, deja de ser una buena medición

Problemas conocidos

• Los problemas de los story points son bien conocidos, pero se siguen usando porque las técnicas de estimación alternativas sufren problemas similares
• Ron Jeffries, creador de los story points, los rechaza y critica su mal uso
• En Scrum, "Commitment" se cambió por "Forecast", pero aun así se sigue usando mal
• Se da la situación paradójica de que incluso hacer más trabajo del estimado puede terminar en reproches

Priorizar con ROI

• Las empresas priorizan el trabajo para optimizar recursos (tiempo, dinero, herramientas y personas)
• Las estimaciones de desarrollo son necesarias para calcular el costo de inversión, pero estimar en sí es difícil y costoso
• Software Estimation: Demystifying the Black Art es un excelente libro que aborda la dificultad de estimar

La salida del proceso

• El proceso de estimación con story points consume mucho tiempo, pero su resultado no aporta valor
• Las sesiones periódicas de grooming consumen mucho tiempo y se aplican de formas variadas sin consistencia entre equipos
• Es más valioso crear una lista de trabajo significativa en lugar de usar story points

Propuesta alternativa

• Estimar con tallas de camiseta puede ser una mejor alternativa, aunque también tiene problemas
• Estimar en tiempo presenta problemas similares, ya que el tiempo real de trabajo del equipo y el tiempo que espera el negocio no son lo mismo
• En equipos pequeños, las estimaciones en tiempo pueden funcionar bien, pero a medida que el equipo crece, la precisión cae
• El libro de Donald Reinertsen, "The Principles of Product Development Flow", presenta una alternativa
  • La clave está en enfocarse en la gestión de colas (Queue) para optimizar el flujo de trabajo
  • Hay que planificar la capacidad y asegurar capacidad de buffer para absorber la variabilidad

La solución

• Todo empieza con el equipo analizando el trabajo en conjunto, dividiéndolo en tareas pequeñas y eliminando la incertidumbre
• La lista de tareas se convierte en una cola (Queue), y el número total de tareas representa el tamaño del trabajo (Job Size)
• En lugar de Story Points, se usa la tasa promedio de finalización de tareas (Average Task Rate) para estimar
• El trabajo se sigue con base en la velocidad promedio de ejecución y se calcula la tasa de finalización de tareas
• Si las tareas se actualizan según nueva información o feedback, la estimación se ajusta de manera natural
• Los desarrolladores ya no tienen que cargar con la presión psicológica de estimar

La cola (Queue) como indicador adelantado

• Mientras que la tasa promedio de finalización de tareas, el Cycle Time y la Velocity son indicadores rezagados, la Queue es un indicador adelantado
• Si el tamaño de la Queue aumenta, se pueden detectar problemas con anticipación y responder a tiempo

Resumen

• Los Story Points generan confusión, no son confiables y están diseñados para fracasar
• En cambio, vale la pena invertir tiempo en que el equipo entienda el problema en conjunto, elimine la incertidumbre, lo divida en tareas y gestione la Queue

Opinión de GN+

• El enfoque de gestión de colas propuesto en el artículo parece una alternativa realista para superar la dificultad de estimar en el desarrollo ágil
• Sin embargo, dividir las tareas en unidades pequeñas puede implicar más esfuerzo para los desarrolladores, y en las etapas iniciales del proyecto puede tomar más tiempo
• Además, el proceso de análisis de tareas presupone la participación activa de los desarrolladores y que expresen sus opiniones con franqueza
• Por otro lado, también puede esperarse el efecto positivo de que el equipo de desarrollo entienda a fondo los requerimientos del negocio y reflexione en conjunto sobre ellos

[heal9179]

¿No es esa la metodología Kanban..?

[GN⁺]

Opiniones en Hacker News

• En mi experiencia personal, el número de story points no era importante, pero el proceso del equipo para evaluar la complejidad del trabajo sí era muy útil

  • Usar story points para predecir el tiempo de trabajo era una métrica poco confiable
  • Intento evitar los story points por varias razones, como los cambios en el equipo y en el dominio, y la variabilidad del trabajo no relacionado con desarrollo
  • En los equipos que usaban story points, se utilizaban como una herramienta para compartir la comprensión del trabajo

• En la guía de Scrum, el cambio de "Commitment" a "Forecast" no ocurrió en 2011

  • Al revisar las guías de 2010 y 2011, la palabra "Commitment" no aparecía en las versiones anteriores a 2011
  • "Forecast" reemplazó a "Estimate" en la guía de 2020

• Descomponer paquetes de trabajo en unidades atómicas y medir la longitud de la cola es un problema de otra dimensión

  • Se pueden usar story points mientras se refinan los paquetes de trabajo con el equipo
  • Descomponer todo el trabajo en tareas de 1 story point era ineficiente
  • Conectar la longitud de la cola con el impacto de la variabilidad es un concepto interesante

• También hay casos en los que el enfoque waterfall y las estimaciones por tiempo funcionan bien

  • En un pequeño equipo de servicios profesionales, se documentan los requisitos del cliente y, después de discutirlos con el equipo, se estiman en rangos de tiempo
  • Si el cliente lo aprueba, se pasa por el proceso de diseño detallado, desarrollo, QA y lanzamiento
  • El proceso no ha cambiado en 20 años, y se considera un equipo muy productivo

• Los story points representan complejidad relativa e incertidumbre, no unidades de tiempo

  • Debería ser posible medir historias con números grandes
  • En algunos equipos no se asignan más de 7 puntos
  • En otros lugares se han asignado 21, 30 o 50 puntos

• Los story points eran, a grandes rasgos, una unidad de tiempo

  • Hacer que los story points coincidan con una unidad de tiempo clara puede llevar a confusión
  • Lo importante es predecir cuánto tiempo dedicará un desarrollador a una tarea
  • Para que el análisis de colas ayude, hay que conocer el tiempo estimado de cada tarea

• Cuando usé Scrum por primera vez, usábamos Rally

  • Se hacía seguimiento de story points, tiempo estimado y tiempo real
  • Después de cambiar a Jira, desapareció el seguimiento del tiempo
  • A medida que mejoró la precisión del tiempo estimado, fue más fácil equilibrar la carga de trabajo del equipo

• Los story points eran útiles para discutir la complejidad del trabajo, pero no servían para medir la velocidad

  • Como ingeniero nuevo, resolvía muchos story points, pero la gerencia intentaba ajustarlo
  • Era difícil evaluar adecuadamente el trabajo complejo

• Es difícil estimar proyectos de desarrollo de software de forma confiable

  • Es importante dividir el trabajo en unidades pequeñas junto con el equipo y estimar rangos de tiempo
  • A medida que avanza el proyecto, es importante reportar la lista de funcionalidades y los nuevos rangos estimados

• Estimar en unidades de tiempo es un mejor enfoque

  • Los story points al final terminan convirtiéndose en unidades de tiempo
  • Es más eficiente evitar los procedimientos complejos de Scrum y simplemente completar el trabajo