Estimación y planificación ágil: puntos, velocidad y previsiones

Toda estimación es una afirmación sobre un trabajo que nadie ha hecho todavía, formulada por personas que aprenderán sobre la marcha cosas que no pueden saber de antemano. No es una falta de profesionalidad; es la definición misma de la situación. Estimar software es difícil porque la mayor parte del esfuerzo se dedica a descubrir cuál es realmente el problema, y ese descubrimiento solo ocurre mientras se construye.

El objetivo útil, por tanto, no es la exactitud. Es producir previsiones lo bastante honestas como para tomar decisiones, lo bastante baratas como para que compense el tiempo, y expresadas de forma que conserven la incertidumbre en lugar de esconderla tras una única cifra rotunda. Esta guía repasa las técnicas que usan los equipos ágiles, cómo prever una release sin fingir y qué tiene de acertado el argumento de no estimar. La planificación clásica basada en redes, que resuelve otro problema, se trata en la gestión del cronograma.

Por qué las estimaciones son inciertas

Se acumulan tres fuentes de error distintas.

Desconocimiento del problema. Los requisitos tal como se formulan son siempre una aproximación de la necesidad. La distancia entre ambos se descubre construyendo, lo que significa que parte del trabajo es, por definición, desconocida al estimar. Eso es lo que describe el cono de incertidumbre: en la fase de concepto, una estimación defendible puede desviarse por un factor de cuatro en cualquier dirección, y el margen se estrecha a medida que se entiende el problema y solo desaparece con la entrega.

Desconocimiento de la solución. Nadie sabe lo fea que es la integración con el sistema legacy hasta que la abre. Las estimaciones de trabajo en partes poco conocidas de un sistema son sistemáticamente peores que las de las partes conocidas, y el error es asimétrico: las sorpresas alargan el trabajo, casi nunca lo acortan.

Sesgos humanos. La gente se imagina el escenario en el que nada sale mal y se ancla en la primera cifra que se dice en la sala. La tendencia a estimar como si el plan fuera a cumplirse está bien documentada, y la corrección no consiste en exigir mejores conjeturas, sino en usar el historial observado de trabajos comparables.

Hay una cuarta fuente, organizativa: una estimación dada bajo presión a un stakeholder que quería un número más pequeño es el resultado de una negociación, no una previsión. Cualquier proceso que castigue las desviaciones generará colchones ocultos, y cualquier proceso que premie el optimismo generará subestimaciones.

Dimensionamiento relativo y story points

La estimación relativa esquiva la pregunta más difícil. Las personas juzgan mal la duración absoluta y son bastante mejores comparando: pregúntale a un equipo si este elemento es más grande que aquel y converge enseguida.

Un story point es una unidad de tamaño relativo que combina volumen, complejidad e incertidumbre. No tiene valor temporal. La escala suele ser una secuencia de Fibonacci modificada —1, 2, 3, 5, 8, 13, 20— porque los saltos crecientes reflejan que la precisión cae a medida que aumenta el tamaño: distinguir un 8 de un 13 es posible; distinguir un 21 de un 23, no. Algunos equipos usan tallas de camiseta por el mismo motivo.

El dimensionamiento relativo solo funciona con historias de referencia: dos o tres elementos terminados que todo el equipo recuerda, fijados a valores concretos. «Añadir un campo obligatorio con validación al formulario existente» es un 2; «la importación CSV con informe de errores» fue un 5. Los elementos nuevos se sitúan por comparación. Sin referencias, el valor de los puntos deriva con los meses y cualquier dato histórico pierde su valor.

El planning poker es el mecanismo habitual. Cada desarrollador tiene una carta, todos la muestran a la vez para que nadie se ancle en la voz más veterana, y quienes quedan en los extremos explican su razonamiento antes de una segunda ronda. La estimación es un subproducto; lo importante es la conversación, porque una gran dispersión casi siempre significa que dos personas se imaginan un alcance distinto. Para backlogs grandes, la estimación por afinidad —ordenar en silencio las tarjetas en una pared por grupos de tamaño y luego asignar valores a los grupos— dimensiona cincuenta elementos en una hora con una precisión suficiente.

Los elementos estimados en 13 o más deberían dividirse, por lo general, antes de entrar en un sprint, usando los patrones de división de la guía del product owner.

La velocidad, bien usada

La velocidad es el número de puntos que el equipo termina —cumpliendo la definition of done— en un sprint. Su único propósito legítimo es ayudar a ese mismo equipo a prever su propio futuro.

Usa un rango, no una media. Un equipo cuyos últimos seis sprints entregaron 26, 31, 18, 29, 33 y 24 puntos tiene una media de 26,8, pero planificar sobre 26,8 es prácticamente jugárselo a cara o cruz. Planificar el sprint en la parte baja y prever la release con toda la dispersión es mucho más informativo. Nunca arrastres la velocidad tras un cambio de equipo, nunca la compares entre equipos y nunca la publiques como productividad: los puntos son una unidad interna, y en cuanto se premian, se inflan.

La velocidad también se degrada en silencio cuando la definition of done es laxa, porque el trabajo sin terminar se cuela en el recuento. Si la velocidad es estable pero nada llega a producción, el número está midiendo actividad.

Prever a partir del flujo

Muchos equipos obtienen mejores previsiones ignorando por completo el tamaño y contando elementos.

El throughput es el número de elementos terminados por unidad de tiempo. El cycle time es el tiempo transcurrido desde que se empieza un elemento hasta que se termina. Ambos se miden, no se estiman, y cualquier herramienta que registre los cambios de estado los proporciona gratis.

La idea detrás de la previsión basada en el flujo es que, cuando un equipo divide de forma consistente, los tamaños de los elementos se agrupan lo suficiente como para que contarlos sea casi tan predictivo como sumar puntos, y no cuesta nada. Si un equipo termina entre cuatro y nueve elementos por semana y quedan ochenta, la release llegará en algún punto entre nueve y veinte semanas, y puedes decirlo desde el primer día.

La simulación de Monte Carlo convierte eso en una distribución. Parte de las muestras históricas de throughput semanal, extrae de ellas al azar de forma repetida para simular la finalización de los elementos restantes, ejecuta diez mil pruebas y lee los percentiles.

Elementos restantes:  80
Muestras de throughput semanal (últimas 12 semanas):
  4, 7, 5, 9, 6, 3, 8, 6, 5, 7, 4, 6

10.000 ejecuciones simuladas — semanas para terminar 80 elementos:
  Percentil 50 (P50)   13 semanas
  Percentil 70 (P70)   15 semanas
  Percentil 85 (P85)   17 semanas
  Percentil 95 (P95)   20 semanas

Mensaje para los stakeholders:
  «13 semanas es cara o cruz. Tenemos un 85 % de confianza en terminar
   en 17 semanas o menos. Comprometerse a 20 semanas es seguro.»

Es una conversación mucho más útil que «la release sale en el tercer trimestre», porque explicita el nivel de confianza y puede recalcularse cada semana a medida que llegan datos reales. Añade un factor de crecimiento del alcance si el backlog suele crecer durante la entrega: un ajuste habitual y a menudo olvidado.

El argumento de no estimar

Una corriente de práctica sostiene que, para muchos equipos, estimar es puro coste. El argumento es más sólido de lo que admiten sus críticos: si los elementos se dividen siempre en piezas pequeñas, la previsión por throughput da la fecha sin estimar nada, y las horas dedicadas a sesiones de dimensionamiento no aportan nada. Además, las estimaciones tienden a convertirse en compromisos por mucho cuidado que se ponga al presentarlas, lo que las corrompe.

Los contraargumentos también son reales. Las conversaciones de estimación sacan a la luz malentendidos que de otro modo se descubrirían a mitad de sprint: el valor está en la discusión, no en el número. Algunas decisiones necesitan de verdad una cifra de coste antes de empezar, como decidir si merece la pena construir una funcionalidad o cuál de dos ofertas contractuales aceptar. Y las organizaciones que financian el trabajo anualmente necesitan algo a lo que asignar el presupuesto.

Una postura razonable: estima al nivel en el que el número cambia una decisión, y detente ahí. Merece la pena producir un tamaño aproximado para una decisión de inversión trimestral; volver a puntuar cada elemento en cada sesión de refinamiento, normalmente no.

Planificación de releases y capacidad

La planificación de releases convierte las previsiones en una expectativa compartida. Las entradas son el backlog ordenado, un rango de previsión, las fechas fijas conocidas y la capacidad real del equipo, no su plantilla. La capacidad se reduce por vacaciones, guardias de soporte, reuniones, incorporaciones y la parte del sprint reservada a defectos, y un equipo de seis rara vez dispone del equivalente a seis personas dedicadas a funcionalidades.

Mantén clara la distinción entre capacidad y compromiso. La revisión de 2020 del framework dejó deliberadamente de describir el sprint backlog como un compromiso con un conjunto de elementos y convirtió el objetivo del sprint en el compromiso, precisamente porque la previsión tomada como promesa se había convertido en el mal uso dominante. Un equipo prevé lo que espera terminar; se compromete con el objetivo.

Para una release, presenta un rango con niveles de confianza, explicita los supuestos y vuelve a prever en cada sprint. Cuando varios equipos comparten una release, el coste de coordinación cambia sustancialmente el panorama: consulta agile a escala. Cuando el riesgo de retraso es relevante, trátalo de forma explícita mediante la gestión de riesgos en lugar de inflar las estimaciones sin que se note.

Ideas clave

• Las estimaciones son previsiones hechas en el momento de máxima ignorancia; el cono de incertidumbre implica que una cifra única temprana engaña y que un rango es honesto.
• El dimensionamiento relativo funciona porque las personas comparan mejor de lo que miden en términos absolutos, y solo se sostiene si el equipo mantiene historias de referencia.
• El planning poker existe para la conversación; una gran dispersión de cartas significa que el alcance se entiende de forma distinta, y ese es el hallazgo que vale la pena.
• La velocidad es un dato de previsión interno de cada equipo expresado como rango; compararla entre equipos o presentarla como productividad la destruye.
• Contar el throughput y ejecutar una simulación de Monte Carlo da una fecha probabilística con niveles de confianza a un coste recurrente casi nulo.
• Estima donde el número cambia una decisión; comprométete con el objetivo del sprint y no con una lista de elementos, y vuelve a prever a medida que llegan datos reales.