Story Points normalizados en SAFe – ¿cómo y por qué?
SAFe4 propone que los Story Points dentro del desarrollo de producto deberían estar estandarizados entre los diferentes equipos. Para ello, SAFe ofrece un método para poder estimar Story Points ya en el primer Sprint. Desde la perspectiva de Scrum, este enfoque parece inicialmente inconsistente con la idea de los Story Points. Para resolver esta contradicción, examinemos la idea más de cerca.
¿Qué son los Story Points?
Los Story Points son, en pocas palabras, una medida arbitraria para cuantificar el esfuerzo de un elemento del Backlog. Deben ayudar a los desarrolladores a planificar mejor su capacidad y al Product Owner a comprender qué es alcanzable en las próximas semanas y meses. Así se pueden predecir, por ejemplo, las fechas y el alcance de entrega de un release.
Mike Cohn propone un beneficio adicional: si se conoce la Velocity y los costos mensuales de un equipo, se pueden hacer estimaciones de costos para los elementos del Backlog. Así se puede optimizar la rentabilidad del desarrollo. Por ejemplo, un elemento del Backlog puede parecer antieconómico una vez que se conocen los costos. De esta manera, el Product Owner puede decidir tempranamente si una Story debe reelaborarse o descartarse por completo.
SAFe retoma esta idea en el concepto WSJF: los Features con la mejor relación costo-beneficio deberían ser priorizados.
Lo más importante para que este enfoque funcione es que todos los involucrados tengan una comprensión común de los Story Points. Dado que los Story Points pueden significar cosas ligeramente diferentes para distintos equipos, hay que tener cuidado al considerar los valores fuera del equipo.
¿Qué son los Story Points normalizados?
En SAFe, la unidad de desarrollo del producto es un Agile Release Train (ART), un “Team of Teams”.
Tan importante como es en Scrum que todos los involucrados dentro del equipo entiendan un Story Point de la misma manera, en SAFe es igualmente importante que todos los involucrados dentro del ART entiendan un Story Point de la misma forma.
Si los equipos interpretaran los Story Points de manera diferente, el Product Manager recibiría estimaciones completamente distintas dependiendo de qué equipo haya estimado un ítem. Las estimaciones resultantes serían completamente inútiles desde la perspectiva del negocio. Con ello, todo el proceso de estimación sería inútil y las estimaciones carecerían de valor.
Por eso SAFe propone que, así como en el equipo Scrum se necesita una comprensión compartida de los Story Points, también los equipos individuales dentro del ART necesitan una comprensión compartida de los Story Points para estimar de manera significativa.
¿Por qué los Story Points individuales por equipo no son buena idea?
En SAFe, todos los equipos del ART comparten un único Program Backlog centralizado y compartido. Este Program Backlog consolida todas las actividades del ART, independientemente de qué equipo realice el trabajo posteriormente.
Un concepto clave de la agilidad es que el trabajo debe ser independiente de la persona, ya que la especialización conduce a la optimización local.
Desde la perspectiva Lean, a menudo es mejor que un equipo más lento comience el trabajo inmediatamente, en lugar de esperar con cosas importantes a que el equipo más rápido esté disponible.
Especialmente cuando varios equipos colaboran, un equipo más lento puede entregar una parte del valor antes de que el equipo más rápido esté disponible para participar. Así se reduce el tiempo total de entrega y la dedicación del equipo más rápido hasta la finalización definitiva.
Si los Story Points difieren entre equipos, cada elemento individual del Backlog tiene que ser estimado por cada equipo individual hasta que se comprenda qué equipo podría terminar cuándo. Esto es posible, pero significa un desperdicio masivo y overhead.
Si, en cambio, los Story Points están normalizados entre equipos, solo se necesita una única estimación de un solo equipo. Al observar la Velocity de los equipos individuales, se puede ver rápida y fácilmente cuánto tardaría.
Un beneficio adicional de los Story Points normalizados es: si el equipo A necesita el apoyo del equipo B para cumplir un plazo importante, el Product Owner del equipo B sabe inmediatamente cuánto debería sacar el equipo B de su Backlog para asumir las Stories del equipo A. Como no se necesita una nueva estimación, no se producen ni retrasos ni esfuerzos adicionales de estimación.
¿Cómo normaliza SAFe exactamente los Story Points?
En el primer Program Increment, el ART es nuevo. Ni los equipos individuales ni las personas en el ART han trabajado jamás en exactamente esta constelación. Los equipos se encuentran en la “fase Storming”, al igual que el propio ART.
Esto a su vez significa: los Working Agreements aún no están claros. La DoD es un ideal difuso que nunca se ha probado en la práctica. Por todas partes pueden haber obstáculos. Dependiendo de cómo se desarrolle el producto, posiblemente el entorno de trabajo también sea nuevo y desconocido. Todos se encuentran en un punto en blanco del mapa: cualquier estimación es pura adivinanza.
Un enfoque posible sería discutir conjuntamente qué Story se elige como referencia, cómo se definen los puntos, cuántos puntos recibe la Story de referencia, y a partir de ahí trabajar. Esta discusión llevará a más discusiones, todas ellas sin generar valor desde la perspectiva del cliente.
SAFe evita este procedimiento y propone lo siguiente: Estimación Relativa.
En el primer PI Planning se comienza seleccionando el ítem más pequeño del Backlog del equipo y asignándole un “1”. Al siguiente ítem más grande se le asigna un “2”, y se avanza utilizando una serie basada en los números de Fibonacci (1,2,3,5,8,13,20,40,100): ¿tenemos un ítem del mismo tamaño que uno conocido? Si es así, recibe el mismo número. Si es el más grande hasta ahora, recibe un número adecuado. Si no tenemos una buena referencia y debemos dar un salto, un “3” sería al menos el doble de grande que un “1”, y un “8” al menos el doble de grande que un “3”, etc. Así, con un procedimiento muy simple y sin conocimiento preciso, se puede formar una estimación de lo que el equipo tiene por delante.
Esto es, por supuesto, pura conjetura y los valores son bastante imprecisos. Pero dado que aún no tenemos valores de experiencia, este procedimiento es tan bueno como cualquier otro. Lo más importante es que los equipos discutan sobre el “Qué”, el “Por qué” y los riesgos potenciales de las Stories.
¿Cómo se calcula la Velocity con Story Points normalizados?
Para enfatizarlo una vez más: en el primer Program Increment no tenemos idea alguna de cuántos Story Points puede completar realmente un equipo. Sin embargo, como tenemos estimaciones en días-persona, SAFe propone el siguiente procedimiento en el primer PI Planning:
Sabemos cuántos miembros tiene nuestro equipo. También sabemos cuántos días planeamos ir a trabajar en una iteración (por supuesto, no sabemos cuándo nos enfermaremos, ese riesgo simplemente permanece).
Una iteración típica de SAFe dura 2 semanas calendario, es decir, tiene 10 días laborables. Este número se puede multiplicar por la cantidad de miembros del equipo:
Capacidad Base = 10 * Miembros del Equipo
De ahí restamos los días en que los miembros del equipo no estarán presentes:
Capacidad Ajustada = Capacidad Base – (Festivos * Miembros del Equipo) – (días de ausencia individuales)
De eso restamos un 20 por ciento más, porque planificar al 100 por ciento de ocupación siempre lleva al desastre.
Velocity Inicial = Capacidad Ajustada * 0.8
Aquí un ejemplo:
El equipo Trolls tiene 6 desarrolladores. En la próxima iteración hay un día festivo y Toni tiene que resolver algo personal el viernes.
Capacidad Base = 106 = 60 SP
Capacidad Ajustada = 60 SP (Base) – 16 SP (Festivos) – 1 SP (Ausencia) = 53 SP
Velocity Inicial = 53 SP * 80 por ciento = 42 SP
El equipo Trolls planificaría entonces la Iteración 1 con 42 Story Points. Si los números de las Stories no encajan exactamente, siempre es mejor quedarse un poco por debajo que sobrecomprometerse. Los Trolls podrían entonces decidir ir a la primera iteración con 39 SP.
¿Qué sucede con el tiempo con los Story Points normalizados?
En la primera iteración simplemente adivinamos. Adivinar es mejor que nada. Y después entra en juego Inspect+Adapt. Quizás los Trolls aprendieron que avanzan por el Backlog como un cuchillo caliente por la mantequilla. Entonces, por supuesto, la próxima vez tomarían algunos Story Points más. Quizás los Badgers aprendieron que tienen que hacer mucho por otros equipos (como por ejemplo transferencia de conocimiento). Entonces en el futuro ya no asumirían tantos Story Points.
Así podría desarrollarse la Velocity del ART con el tiempo:
Como vemos en este ejemplo, los equipos utilizan Inspect+Adapt individual y controlan su propia Velocity. El Product Manager recibe feedback regularmente para ajustar la planificación global del producto y los objetivos del PI (así como, en su caso, los objetivos de Release).
Las reestimaciones de elementos del Backlog previamente estimados se eliminan. Cuando surgen nuevos temas, se pueden usar Stories “Done” como referencia para estimar futuros elementos del Backlog de forma consistente con los elementos existentes y pasados. La vinculación con los días-persona desaparece.
Precaución con los Story Points normalizados
¡Los Story Points no son una métrica de negocio! Tampoco la Velocity. Son métricas de planificación simplificadas que minimizan el esfuerzo de planificación y al mismo tiempo proporcionan suficiente confianza en la viabilidad.
Estas métricas están sujetas en el ART a las mismas limitaciones que en Scrum con un solo equipo. Se deben evitar los siguientes antipatrones.
Bajo ningún concepto se debe:
Considerar las estimaciones como “correctas”. Son y seguirán siendo estimaciones.
Medir el progreso en base a “Story Points entregados”. ¡Los productos utilizables son la métrica de progreso principal!
Comparar equipos en base a su Velocity. ¡La Velocity no es una métrica de rendimiento!
Optimizar la estructura del ART en función de los valores de Velocity. ¡Un ART es un sistema adaptativo altamente complejo!
Intentar mantener la Velocity constante o en aumento. La planificación de capacidad es minimización de riesgos. Está sujeta a la realidad. ¡La Velocity es solo un indicador que aumenta la fiabilidad de la planificación!
¿Cuándo se deben aplicar los Story Points normalizados?
La normalización de Story Points resuelve un problema que sin escalamiento simplemente no existe. Responde a la pregunta “¿Qué pasa si otros equipos trabajan en esta Story?” Para ello, la comprensión de un Story Point debe ser uniforme entre equipos.
Así, en el ART los elementos del Backlog pueden moverse relativamente fácil entre equipos, para maximizar el valor total del producto entregado en lugar de la ocupación de equipos individuales.
Hasta que haya mejor información disponible, con un benchmark muy sencillo y estimación relativa se puede obtener una buena visión general. De las Stories completadas se pueden elegir Stories “adecuadamente estimadas” y memorables como referencia para el futuro. No hay reestimaciones. La relación inicialmente asumida entre Story Points y días-persona desaparece en muy poco tiempo. Esto debe suceder para que los Story Points sean consistentes entre equipos.
También para la planificación inicial de la Velocity utilizamos, a falta de mejor información, la regla simple del “80 por ciento del tiempo disponible”. Una vez completada la primera iteración, usamos el resultado real como referencia para el futuro y nos adaptamos. En pocas iteraciones, la correlación de la Velocity con la capacidad temporal también se disuelve. Esto también debe suceder para que la Velocity pueda utilizarse como herramienta de planificación de manera consistente y significativa en el ART.
En el ART es aún más difícil que en Scrum con un solo equipo resistir la tentación de evaluar equipos en base a la Velocity. El RTE tiene la importante tarea de garantizar la integridad de los Story Points, impidiendo cualquier intento (generalmente por parte de la dirección) de desvirtuar los Story Points o la Velocity.
