Story Points vs Man Days: el debate mal planteado

La estimación relativa y los story points son algunos de los temas que más confusión generan, tanto en formaciones como en clientes. El problema principal suele ser la creencia de que, tarde o temprano, los Story Points (SP) deben traducirse en Man Days (MD) si se quiere hacer planificación de capacidad, estimaciones o gestión de portafolio. Y por eso, muchas personas no llegan a comprender las verdaderas razones para usar estimación relativa. Aún peor: centrarse en el concepto abstracto de los MD les impide ver el panorama completo y lo que realmente importa: el valor.

Cuando hablo de esto con clientes, siempre intento destacar que hay dos cuestiones distintas en juego:

1. cómo encajar la estimación relativa en un proceso existente basado en MD
2. cómo el foco en MD impide a los gestores ver el verdadero problema

Usar estimaciones relativas en organizaciones basadas en MD

La moneda de los Man Days es una restricción que los coaches ágiles rara vez pueden evitar al trabajar con organizaciones. A menudo, toda la estructura de planificación y presupuestos de la empresa se basa en MD, y cambiar esa estructura no forma parte del alcance de la iniciativa ágil (al menos por ahora). Lo que los gestores quieren saber es cómo pueden usar estimaciones relativas dentro de esa lógica basada en MD.

Después de haber hecho este ejercicio con la mayoría de los clientes con los que he trabajado, he encontrado que la forma más simple de explicarlo es escribiendo tres ecuaciones en la pizarra, así:

Explico que la primera línea (estimación x factor = esfuerzo) es la fórmula que todo el mundo usa para obtener MD, independientemente de la metodología o disciplina.

La segunda línea es cómo funciona esa fórmula en el mundo Waterfall: el equipo estima en MD, y el gestor aplica un factor de conversión para tener en cuenta el tiempo no productivo y la carga adicional del equipo, obteniendo así un número de MD para presupuesto y planificación.

La tercera línea es cómo se pueden obtener los MD usando estimación relativa. En esa ecuación, el factor de velocidad = MD por Sprint / Velocidad.

Objeciones de los gestores: dos críticas frecuentes

Hasta aquí, todo claro: los gestores entienden la ecuación. Pero es entonces cuando comienzan las preguntas. En un caso reciente, un gestor de equipo cuestionaba este modelo con dos críticas básicas:

• El "factor de velocidad" (MD por SP) es básicamente una tasa de cambio para los MD. Si el equipo no tiene una velocidad consistente (como era el caso de sus equipos Scrum), esa tasa fluctúa demasiado y las estimaciones acaban siendo incorrectas.
• Los Story Points son demasiado abstractos, y si las dos fórmulas son prácticamente lo mismo, ¿por qué no estimar directamente en MD?

Ambas críticas me ayudaron a ver la raíz del problema.

Crítica #1: la velocidad fluctúa demasiado

Si la velocidad de un equipo fluctúa mucho, las estimaciones en MD basadas en esa conversión seguramente serán incorrectas. Nunca hay que olvidar que Scrum no resuelve tus problemas: los hace dolorosamente visibles. Y eso es exactamente lo que estaba ocurriendo aquí. Aún queda trabajo por hacer para solucionarlos.

Este gestor debería hablar con su equipo sobre por qué su velocidad varía tanto, y escuchar atentamente su feedback. Es muy probable que estos temas ya hayan surgido en retrospectivas (como fue el caso). El foco del gestor debería estar en eliminar esos impedimentos, ayudar al equipo a entregar de forma más consistente, y no en intentar mejorar mágicamente su capacidad de estimar.

Crítica #2: los Story Points son demasiado abstractos

Volví a la pizarra y dibujé dos círculos rojos:

Sí, las fórmulas eran muy parecidas (ambas igual de simples), pero la diferencia está en el foco. En la fórmula Waterfall no se tiene en cuenta la productividad. El objetivo es que la estimación sea precisa, porque el factor de carga es fácil de calcular y no fluctúa mucho.

En cambio, la versión ágil da un giro: deja de centrarse en la estimación. La estimación relativa no es difícil y puede aprenderse en una hora. Más allá de probar distintas técnicas (estimación por equipo, planning poker…), no hay mucho que mejorar ahí. El foco está en el factor de velocidad, que es una medida de productividad. Si ese factor cambia drásticamente o tiene una tendencia negativa, los agilistas queremos saber por qué. Buscamos los problemas reales que impiden un ritmo de trabajo sostenible y productivo.

Nota: la velocidad es una medida imperfecta de productividad. Usarla como barómetro de la capacidad de entrega del equipo y como insumo para retrospectivas es muy útil, pero convertirla en objetivo de rendimiento es perder el norte. Como cualquier métrica imperfecta, se puede manipular. No pierdas tiempo intentando usarla como métrica de rendimiento del equipo.

Si la velocidad de tu equipo es demasiado impredecible, no hay fórmula que lo solucione. Hay que implicarse y descubrir qué está pasando. Muy a menudo, está relacionado con los conflictos que los gestores evitan por razones políticas: dependencias con otros equipos, datos de prueba inconsistentes a nivel corporativo, mala gestión de producto, malas prácticas técnicas… Si quieres mejorar la entrega, empieza por ahí.

Fijarse en los MD es perder el foco

Los MD están tan presentes en la mente de los gestores porque es la moneda aceptada en las organizaciones IT. Tan común que muchos olvidan que no es el objetivo, sino una capa de abstracción que intenta representar el siempre mencionado pero difícil de medir “valor de negocio”.

Nota: en el mundo corporativo, valor suele significar beneficio, pero no tiene por qué ser dinero. Puede depender del propósito de tu organización: satisfacción del cliente, vidas salvadas, calidad...

En lugar de buscar formas de medir ese valor, muchos gestores se sienten cómodos en esa capa abstracta de los MD. Esto da lugar a métricas de éxito equivocadas, como “desviación de la estimación inicial”. Solo refuerzan la obsesión por acertar en los MD y alimentan la falsa creencia de que todo debe traducirse a ellos.

Estimar no es tener éxito

Digo que este debate está mal planteado porque he visto muchos gestores perder de vista lo que realmente importa. He oído a varios decir que su prioridad número uno era entregar proyectos dentro del presupuesto (MD). No mejorar el rendimiento de sus equipos, ni reducir deuda técnica o el time-to-market. No: clavar la estimación.

Es decir: “Me da igual si entregamos algo de poca calidad, mientras lo entreguemos de forma predecible”.

Y eso es un problema. Mientras los gestores no estén dispuestos a soltar el foco en la predictibilidad para centrarse en la productividad, seguirán siendo un impedimento para que sus equipos mejoren. Porque es natural que los equipos perciban esa obsesión por la previsibilidad por encima de la creación de valor y actúen en consecuencia.

Lo que de verdad importa: entregar valor

El cambio de mentalidad que hace falta es entender que el foco debe estar en entregar valor. Y para lograrlo, ni siquiera los SP son suficientes. Solo miden cuánto trabajo puede entregar un equipo. Las organizaciones que quieren mejorar su capacidad de entregar valor, primero tienen que aprender a medirlo.

De hecho, es bastante evidente que esa incapacidad para medir valor es lo que lleva a muchos gestores a centrarse en el coste. Es difícil decir cuán valiosa es una historia (o un proyecto), pero calcular la desviación presupuestaria requiere poco más que matemáticas básicas.

El movimiento #NoEstimates ha generado bastante ruido últimamente. Vasco Duarte escribió un buen resumen para quienes tengan interés.

No discrepo (mi doble negación favorita) con nada de lo que plantean, salvo que no me gusta el nombre (todo el mundo estima, incluso en el modelo que proponen), y tampoco creo que estén describiendo una revolución, sino un estado avanzado de organizaciones que aplican Lean Thinking.

Conclusión

Prefiero pensar en la estimación como desperdicio. Estimar mejor no es lo que hará exitosa a tu organización ni lo que te permitirá lanzar ese producto revolucionario al mercado. Aunque no aporte valor directo, es parte inherente de la gestión de producto y el desarrollo de software. Y reducir ese desperdicio es un camino progresivo y continuo.