Estimación relativa vs. absoluta: ¿Cuál es mejor?
La estimación es uno de los temas más debatidos en el desarrollo de software ágil. Los equipos se enfrentan constantemente a la pregunta: ¿debemos estimar en horas y días, o deberíamos usar escalas relativas como los puntos de historia? Los dos enfoques predominantes —la estimación relativa y la estimación absoluta— tienen casos de uso legítimos, y ninguno es universalmente superior. Comprender sus diferencias es el primer paso para elegir el método adecuado para tu equipo.
¿Qué es la estimación absoluta?
La estimación absoluta consiste en asignar una unidad de medida concreta y específica a una tarea. Generalmente es tiempo: horas, días o semanas. Cuando un desarrollador dice “esta funcionalidad tardará tres días”, está usando estimación absoluta.
Las estimaciones absolutas resultan intuitivas porque los seres humanos estamos acostumbrados a pensar en unidades del mundo real. Los stakeholders suelen preferir las estimaciones absolutas porque se traducen directamente en plazos de entrega y planificación de recursos. Para un jefe de proyecto que construye un calendario de lanzamiento, saber que una funcionalidad tardará cinco días es más inmediatamente útil que saber que cuesta ocho puntos de historia.
Sin embargo, la estimación absoluta tiene una debilidad significativa: es notoriamente difícil de hacer con precisión. Las investigaciones muestran sistemáticamente que los desarrolladores subestiman la complejidad de las tareas, especialmente cuando trabajan con tecnología desconocida o sistemas con muchas dependencias. Sesgos cognitivos como el sesgo de optimismo y la falacia de planificación hacen que las predicciones de tiempo sean poco confiables.
¿Qué es la estimación relativa?
La estimación relativa desplaza el foco lejos de las mediciones de tiempo exactas y lo centra en la comparación. En lugar de preguntar “¿cuánto tiempo llevará esto?”, el equipo pregunta “¿qué tan compleja es esta tarea en comparación con otra que ya hemos estimado?”
Las herramientas comunes para la estimación relativa incluyen los puntos de historia, la secuencia de Fibonacci (1, 2, 3, 5, 8, 13…) y las tallas de camiseta (S, M, L, XL). En las sesiones de planning poker, los equipos asignan estos valores relativos a las historias de usuario, anclando las nuevas estimaciones en referencias ya conocidas.
La idea central detrás de la estimación relativa es que los seres humanos somos mucho mejores comparando cosas que midiéndolas de forma aislada. Es difícil decir exactamente cuánto mide un edificio, pero es fácil decir que es más alto que el de al lado.
Ventajas y desventajas de cada enfoque
La estimación absoluta ofrece números concretos a los stakeholders y se integra naturalmente con las herramientas tradicionales de gestión de proyectos. Funciona bien cuando las tareas son rutinarias, bien comprendidas y de alcance reducido. La desventaja es que tiende a producir estimaciones excesivamente optimistas y puede generar presión sobre los miembros del equipo para cumplir plazos que nunca fueron realistas.
La estimación relativa reduce el estrés al alejarse de los compromisos basados en el reloj y fomenta la colaboración del equipo. Escala mejor en proyectos grandes y complejos donde la incertidumbre es alta. La desventaja es que requiere un período de calibración: los equipos nuevos necesitan construir un marco de referencia compartido antes de que las estimaciones tengan sentido. Los stakeholders no familiarizados con los puntos de historia también pueden tener dificultades para interpretar los resultados.
Cuándo usar cada método
Usa estimación absoluta cuando:
- Las tareas están bien definidas y son rutinarias
- Los stakeholders necesitan previsiones de entrega basadas en tiempo
- El equipo cuenta con datos históricos extensos
- El proyecto es a corto plazo y está muy acotado
Usa estimación relativa cuando:
- El proyecto es grande, complejo o tiene una incertidumbre considerable
- El equipo quiere fomentar debates abiertos sobre el alcance y los riesgos
- Se está construyendo un backlog a largo plazo que necesita repriorización frecuente
- La velocidad del equipo debe rastrearse a lo largo de varios sprints
Conclusión
Elegir entre estimación relativa y absoluta no es una cuestión de cuál es objetivamente mejor. Es una cuestión de adecuación. Muchos equipos ágiles experimentados usan la estimación relativa internamente para la planificación y el seguimiento de la velocidad, mientras traducen sus datos de velocidad en proyecciones de tiempo aproximadas para comunicarse con los stakeholders. Este enfoque híbrido aprovecha los beneficios de ambos mundos.
En última instancia, el mejor método de estimación es el que tu equipo usa de forma consistente y honesta. La estimación es una herramienta para reducir la incertidumbre, no para eliminarla. Cualquiera que sea el enfoque elegido, siempre deja margen para las sorpresas.