Los puntos de historia no miden horas (y confundirlos sale caro)
Cada pocos meses se repite la misma escena. Un product manager entra en la reunión de planificación, el equipo asigna puntos de historia a un puñado de tickets y, acto seguido, alguien saca una hoja de cálculo que convierte esos puntos en horas para poder prometer una fecha de entrega a los stakeholders.
Y en ese instante, todo el sentido de los puntos de historia se viene abajo.
Lo he visto en startups, en scale-ups y en empresas que ya deberían tenerlo aprendido. La causa de fondo es siempre la misma: un malentendido básico sobre qué se supone que miden los puntos de historia, y una cultura de gestión incapaz de resistirse a traducirlo todo a un calendario.
Qué miden realmente los puntos de historia
Los puntos de historia son una unidad de complejidad relativa. Comparan el esfuerzo de una pieza de trabajo con el de otra, incorporando complejidad, incertidumbre y riesgo — no horas de reloj.
Cuando un equipo dice «esto es un 5 y aquello un 2», está diciendo que la primera tarea es unas 2,5 veces más compleja que la segunda. No está diciendo que la primera lleve 5 horas ni 5 días. El número es relacional, no absoluto.
Esta distinción importa porque:
- Dos desarrolladores pueden completar la misma historia de 5 puntos en tiempos muy distintos. Uno conoce mejor el código. El otro depura más rápido. La complejidad del problema es la misma para ambos.
- Una historia de 5 puntos puede llevar más tiempo este sprint que el anterior. Cambios de contexto, incidentes en producción, rotación en el equipo: todo eso afecta a la duración, pero no a la complejidad.
- La complejidad se puede estimar; la duración, no. Los ingenieros somos razonablemente buenos comparando la dificultad de dos tareas, y pésimos prediciendo cuántas horas llevará algo. Los puntos de historia se apoyan en la fortaleza y esquivan la debilidad.
En el momento en que empiezas a decir «1 punto = medio día», has abandonado la estimación relativa y has vuelto a las estimaciones de tiempo, solo que con pasos de más.
Por qué los managers convierten puntos en tiempo (y el daño que causa)
Lo entiendo. Si eres product manager o CEO, necesitas responder a «¿cuándo estará listo?». Es una pregunta legítima. El problema es el atajo: coger los puntos de historia y dividirlos por una «velocidad» para fabricar una fecha.
Esto es lo que pasa de verdad cuando lo haces:
Los equipos empiezan a trucar los números. Si la dirección trata los puntos como tiempo, los ingenieros aprenden a inflar las estimaciones para que no les presionen por «comprometerse» a demasiados puntos. Lo que era un 3 pasa a ser un 5. Lo que era un 5 pasa a ser un 8. Los números dejan de significar nada.
La velocidad se convierte en una métrica de rendimiento. En lugar de una herramienta de planificación, la velocidad pasa a ser un marcador. Se premia a los equipos que «entregan» más puntos. Los equipos empiezan a trocear historias artificialmente o a hinchar estimaciones para parecer más productivos. Estás midiendo lo que no toca e incentivando justo el comportamiento equivocado.
La confianza se erosiona. Los ingenieros se sienten vigilados, no respaldados. Dedican más energía a gestionar expectativas que a resolver problemas. La planificación del sprint deja de ser una conversación colaborativa sobre qué es realista y se convierte en una negociación en la que las dos partes van de farol.
La precisión de las estimaciones empeora, no mejora. La ironía es cruel: cuanto más presionas para conseguir estimaciones de tiempo precisas, menos fiables se vuelven. La presión introduce sesgo. El sesgo destruye la señal.
Alternativas que sí funcionan
Si en tu equipo los puntos de historia se están usando mal, tienes opciones. A algunos equipos les va mejor cambiando de enfoque por completo.
Tallas de camiseta
En lugar de números, usa S/M/L/XL. Es deliberadamente impreciso, y esa es precisamente la gracia. Obliga a hablar de tamaño relativo sin la ilusión de precisión matemática. Un product owner puede mirar un roadmap lleno de medianas y grandes y hacerse una idea aproximada del alcance sin que nadie finja que una L equivale exactamente a 3,5 días.
El movimiento no-estimates
Esta es más radical: deja de estimar historias individuales por completo. Céntrate en partir el trabajo en piezas pequeñas y de tamaño parecido, y mide el throughput. Si tu equipo completa de media 12 elementos por sprint y el backlog tiene 36 de tamaño similar, puedes prever «unos 3 sprints» sin asignar jamás un número a ninguna historia concreta.
Funciona mejor cuando hay disciplina al descomponer historias. Si unas historias son diminutas y otras enormes, la previsión basada en throughput se desmorona.
Previsión por tiempo de ciclo
Es mi enfoque preferido para equipos con al menos unos meses de datos históricos. En lugar de estimar hacia delante, miras hacia atrás: cuánto tarda el trabajo en realidad.
El tiempo de ciclo es lo que transcurre desde que el trabajo empieza hasta que está terminado. Si lo registras por historia o por ticket, puedes calcular percentiles:
- «El 85% de nuestras historias se completa en 7 días.»
- «El 50% se completa en 3 días.»
Ahora, cuando alguien pregunta «¿cuándo estará listo?», das una respuesta probabilística: «Según nuestro historial, hay un 85% de probabilidades de que esté terminado en 7 días laborables». Es más honesto, más defendible y más útil que cualquier estimación basada en puntos.
Herramientas como Jira, Linear o Shortcut generan datos de tiempo de ciclo. No necesitas nada sofisticado: una hoja de cálculo con la fecha de inicio y la de finalización de cada historia te da el 80% del valor.
Cuándo estimar aporta valor
No estoy en contra de la estimación. Estimar es útil cuando sirve a un propósito claro:
- Dimensionar iniciativas grandes. Cuando tienes que decidir entre dos proyectos que pueden llevar 3 o 9 meses, una estimación gruesa ayuda a asignar recursos y fijar expectativas. Aquí funcionan bien las tallas de camiseta o el story mapping.
- Detectar incógnitas. Si el equipo no se pone de acuerdo en si algo es un 3 o un 13, ese desacuerdo es el valor. Saca a la luz supuestos distintos, requisitos que faltan y complejidad oculta. La conversación alrededor de la estimación vale más que el número.
- Planificar capacidad. Saber aproximadamente cuánto trabajo cabe en un sprint ayuda a los equipos a no comprometerse de más. Pero esto solo funciona si proteges las estimaciones para que nadie las convierta en plazos arrojadizos.
Cuándo estimar es puro desperdicio
Estimar no aporta nada cuando:
- Todas las historias tienen un tamaño parecido. Si tu equipo ya domina el arte de partir el trabajo en trozos pequeños, las estimaciones sobran. Cuenta historias y listo.
- Las estimaciones no alimentan ninguna decisión. Si nadie las usa para tomar una decisión de planificación, estás gastando 30 minutos por sprint en un ritual que no produce nada.
- Las estimaciones sirven para culpar, no para planificar. «Dijiste que esto era un 3 y ha tardado una semana.» Si esa frase se ha pronunciado alguna vez en tu equipo, tu proceso de estimación hace más daño que bien.
El objetivo real: previsibilidad, no precisión
Esto es lo que casi todo el mundo pasa por alto: el objetivo de cualquier práctica de estimación es la previsibilidad, no la precisión. No necesitas saber que la funcionalidad X llevará exactamente 14 días. Necesitas saber que tu equipo puede entregar con fiabilidad un conjunto de funcionalidades dentro del trimestre. Es un problema distinto, y se resuelve con métricas de flujo, no afinando la bola de cristal.
Registra el tiempo de ciclo. Mide el throughput. Vigila los límites de trabajo en curso. Son indicadores retrasados que reflejan la realidad, no indicadores adelantados que reflejan deseos.
Los equipos con los que he trabajado que entregan con mayor previsibilidad no son los que tienen los rituales de estimación más sofisticados. Son los que mantienen el trabajo pequeño, limitan el WIP y usan datos históricos para prever. Sin planning poker.
En Conectia, los ingenieros senior que integramos en tus equipos entienden esto. Han pasado por suficientes equipos como para saber que el teatro de la estimación hace perder el tiempo a todo el mundo, y traen hábitos prácticos — PRs pequeños, alcance claro, throughput consistente — que vuelven predecible tu entrega sin convertir la planificación del sprint en una negociación. Eso es lo que hacen los ingenieros con experiencia: hacen funcionar el proceso, no solo el código.
¿Harto de que el teatro de la estimación frene a tu equipo? Habla con un CTO.
