Horas vs. Tamaños vs. Conteos

Los humanos son malos estimando tiempo absoluto, y los ingenieros no son la excepción. La investigación sobre la falacia de planificación — la tendencia sistemática a subestimar cuánto tardarán las tareas — muestra consistentemente que las personas subestiman por un factor de 2 a 4, incluso para tareas que ya han hecho antes. El problema no es pereza o incompetencia. El problema es cognitivo: cuando imaginas hacer una tarea, imaginas el camino feliz. No imaginas la suite de pruebas inestable, los criterios de aceptación poco claros, la dependencia que se actualizó la semana pasada, o las dos horas que pasarás en reuniones.

Las horas también invitan al sesgo de anclaje. Una vez que alguien dice "eso probablemente son unas 4 horas", cada estimación subsecuente orbita alrededor de 4. Si la primera persona hubiera dicho 12, el grupo habría convergido en un número diferente — no porque el trabajo cambió, sino porque el ancla cambió. Las horas se sienten precisas de una manera que invita a una falsa confianza. "Esta es una tarea de 6 horas" suena como un hecho. Es una suposición vestida con bata de laboratorio.

La solución no es "mejorar en estimar horas". Décadas de evidencia dicen que eso no funciona. La solución es dejar de usar una unidad de medida que desencadena la falacia de planificación en primer lugar y cambiar a algo relativo.

La estimación relativa evita la falacia de planificación al preguntar "¿qué tan grande es esto comparado con algo que ya hicimos?" en lugar de "¿cuántas horas tomará esto?" No estás prediciendo el futuro — estás comparando.

Las escalas más comunes son tallas de camiseta (S, M, L, XL) y números estilo Fibonacci (1, 2, 3, 5, 8, 13). Ambas funcionan porque son deliberadamente imprecisas. No hay diferencia significativa entre un 6 y un 7, así que la escala no ofrece esas opciones. Fibonacci te fuerza a usar cubetas, y las brechas entre cubetas crecen conforme los números se hacen más grandes — lo cual coincide con la realidad. La diferencia entre un 1 y un 2 es significativa. La diferencia entre un 13 y un 15 es ruido.

La clave para hacer que la estimación relativa funcione son las historias de referencia. Elige dos o tres tickets completados que todo el equipo recuerde y asígnales tamaños: "el rediseño de la página de login fue un 5, la corrección de exportación CSV fue un 2, la integración de pagos fue un 13". Ahora cada ticket nuevo se compara con esas referencias, no con una escala de tiempo abstracta. "¿Esto se parece más a la corrección CSV o al rediseño de login?" es una pregunta que los ingenieros pueden responder con confianza. "¿Cuántas horas tomará esto?" es una pregunta que responderán mal.

El método de estimación más simple es no estimar en absoluto — solo contar tickets. Si tu equipo completa alrededor de 12 tickets por sprint, y el backlog tiene 15 tickets en el siguiente sprint, sabes que estás sobrecargado sin estimar ni uno solo.

Contar funciona cuando los tickets son aproximadamente del mismo tamaño, lo que significa que funciona cuando los equipos son disciplinados con la división. Un ticket que dice "construir todo el sistema de notificaciones" y un ticket que dice "agregar una verificación de nulo al endpoint de exportación" no son unidades comparables. Pero un equipo que consistentemente escribe tickets dimensionados de medio día a dos días de trabajo — donde el ticket más grande es como máximo 3–4 veces el más pequeño — puede usar el conteo de tickets como un proxy confiable de capacidad.

La disciplina que esto requiere es la división de historias: dividir el trabajo en piezas lo suficientemente pequeñas para que la variación de tamaño sea baja. Eso no es gratis. Pero tiene un beneficio secundario que puede ser más valioso que la estimación misma — los tickets pequeños y bien definidos son más fáciles de revisar, más fáciles de probar, y menos propensos a quedarse "en progreso" por una semana. El método de estimación recompensa exactamente el comportamiento que quieres del equipo de todos modos.