Time For SAFe Episodio 1: Story points

Kevin Bendeler, en su artículo I don’t like SAFe, afirma que “Nothing in any agile method suggests that we need to measure work units (i.e. story points) in uniform manners across teams”.

¿Impide esto que SAFe sea la solución que promete ser para escalar la agilidad? ¿Es cierto que SAFe utiliza los puntos de historia de manera comparativa entre equipos? ¿Cómo lo hace? ¿Para qué?

Damos inicio al debate.

¿Habla SAFe de “story points”?

Efectivamente SAFe sugiere métodos para estimar el trabajo de los equipos.

Los equipos ágiles utilizan puntos de historia para estimar, y utilizan esta estimación relativa para comparar una historia con otra. Parte de la labor de los equipos en una PI Planning, es calcular su capacidad para poder comprometer el alcance de sus entregas con el resto de los equipos involucrados en la implementación, y de este modo, coordinar de manera conjunta la consecución de los objetivos del PI.

¿Cómo utiliza SAFe los puntos de historia?

Estimar la capacidad del equipo en base a puntos de historia les ayudará a conocerse, a lograr una visión compartida del trabajo y a aprender de su propia velocidad de entrega de valor, de manera iterativa e incremental, tal y como se desarrollan los proyectos en los marcos ágiles (i.e., Scrum). Así, pueden analizar cada historia considerando todas las variables a las que se enfrentan durante el desarrollo: su complejidad y su tamaño, la incertidumbre del entorno, las dificultades técnicas, los criterios de aceptación o su verdadera disponibilidad (ausencias, vacaciones, formaciones, bajas médicas u otros compromisos previamente adquiridos). Utilizando su velocidad histórica como punto de partida, el equipo puede realizar los ajustes necesarios para determinar la capacidad real de la iteración y comprometerse con convicción con los objetivos del PI, hasta donde considera que es capaz de llegar.

¿Para qué utiliza SAFe los puntos de historia?

Lo que SAFe denomina “normalizar” es que el punto de historia signifique lo mismo para todos los equipos, que la referencia base sea un tipo de historia similar para dar un valor de partida estimado parecido. Las velocidades de los equipos individuales serán singulares y dependerá de la realidad de cada equipo, pero es importante que todos usen la misma unidad de medida.

El objetivo de esta “normalización” no es otro que escalar los puntos de historia a nivel de feature y de las grandes funcionalidades del tren (ART), para poder así determinar su velocidad. Esto ayuda al establecimiento de la capacidad del tren y de un criterio compartido sobre costes, pero nunca se debe utilizar para medir y comparar la eficiencia entre equipos.

Otro caso en el que se habla de “normalización” es en el que un equipo novel, sin histórico ni experiencia previa, o con un nivel aún bajo de madurez, puede iniciar sus estimaciones en base a las de otros equipos de características similares, y cuya disponibilidad para el PI siguiente sea semejante.

La estimación es un mecanismo de comunicación, una forma de establecer un diálogo y un compromiso en base a hechos históricos. El equipo compara su trabajo en un PI con su propia ejecución en PIs anteriores: es una herramienta del tren para el tren, de los equipos para los equipos. Utilizarla para comparar equipos entre ellos instaría a sus miembros a dedicar parte de su esfuerzo a la realización de un trabajo infructuoso, farragoso y baldío, desvirtuando el propio sentido de la estimación y su utilidad para el equipo, y con una nula aportación real de valor a la organización.

Si la comparativa entre dos historias de dos equipos, estableciendo un punto de partida común que permita orientar la velocidad y la asignación de recursos económicos, deriva en la comparativa en términos de eficiencia de cada uno de estos equipos, se convierte en un anti-patrón ligado más a las personas y roles, que a las prescripciones del marco de trabajo en sí. Lamentablemente es común en transformaciones que, utilizando SAFe como bandera, se personalizan o se construyen desde la inexperiencia o el desconocimiento, y sin tener en cuenta el principal sustento de cualquier transformación ágil, lo que garantiza, a largo plazo, la coherencia, la solidez y la sostenibilidad de la transformación: los principios y valores ágiles.