Story points frente a horas: por qué tu equipo debería dejar las horas
Las estimaciones en horas parecen más concretas que los story points. También suelen ser más erróneas, más estresantes y más difíciles de usar para aprender. Por eso dar el cambio mejora la planificación.
El problema de las horas
Las horas implican una precisión que no existe. Cuando un desarrollador dice "esto llevará 6 horas", está contando con condiciones perfectas: sin interrupciones, sin complejidad inesperada, sin dependencias bloqueadas. El desarrollo de software real no es nada de eso.
Cuando la tarea de 6 horas acaba llevando 14, alguien tiene que explicar por qué. Esa explicación suele consistir en justificar la estimación original en lugar de aprender de lo que pasó realmente.
Lo que capturan los story points
Los puntos capturan complejidad relativa, no tiempo de calendario. Un 5 es aproximadamente el doble de complejo que un 3. Este enfoque es más honesto: a los desarrolladores se les da mejor comparar tareas entre sí que predecir una duración absoluta. (Esa comparación solo sigue teniendo sentido si calibras tu escala con trabajo real).
Las horas hacen responsables a las personas de problemas del sistema
Si el desarrollador A dijo que una tarea llevaría 8 horas y llevó 20, la culpa recae en la estimación de A, aunque el retraso viniera de esperar una decisión, de un conflicto de merge o de un pipeline de CI roto. Las horas individualizan lo que a menudo son problemas del equipo o del sistema.
Los puntos estiman el esfuerzo del equipo para planificar como equipo. No son un compromiso de tiempo personal.
La transición es incómoda
Abandonar las horas suele encontrar resistencia en las partes interesadas que quieren saber "¿cuánto va a tardar esto?". La respuesta honesta es: convierte tu velocidad media en semanas de calendario y añade un margen. Es más preciso que sumar estimaciones en horas ficticias.
Cuándo sí tienen sentido las horas
Las horas siguen teniendo dos usos: estimar tareas individuales en un plan de proyecto detallado (no en un backlog de sprint) y registrar el tiempo real para facturar. Para planificar el sprint y dimensionar el backlog, son la herramienta equivocada. (Y para algunos equipos, prescindir por completo de los story points es la tercera opción honesta).
Los puntos no eliminan la incertidumbre; nada lo hace. Simplemente dejan de fingir que no existe.
