¿Qué significa estimar en Agile y desarrollo de software?

Estimar en el contexto ágil es el proceso de predecir el esfuerzo, la complejidad y la incertidumbre asociados a una tarea, historia de usuario o feature antes de que el equipo comience a trabajar en ella. No se trata de calcular un tiempo exacto, sino de generar una aproximación relativa que ayude a planificar y priorizar.

Según el Standish Group CHAOS Report, los proyectos de software tienen una tasa de éxito del 31%, y la mala estimación es una de las principales causas de fracaso. Un estudio de Steve McConnell, autor de Software Estimation: Demystifying the Black Art (Microsoft Press, 2006), encontró que las estimaciones iniciales de proyectos de software tienen un margen de error típico de 4x: un proyecto estimado en 3 meses puede tardar entre 1.5 y 12 meses.

Como señala Mike Cohn, autor de Agile Estimating and Planning (Prentice Hall, 2005): "Las estimaciones no son compromisos. Una estimación es una predicción informada, no una promesa. Confundir ambas es la fuente de la mayoría de los problemas en la planificación de software."

Estimación absoluta (tradicional)

En la gestión de proyectos tradicional, se estima en unidades de tiempo: horas, días o semanas. Este enfoque tiene varios problemas:

• Las personas son malas estimando tiempo, especialmente para tareas complejas
• Las estimaciones en tiempo generan compromisos implícitos que el equipo siente como obligaciones
• No tienen en cuenta la variabilidad entre personas del equipo
• Crean una falsa sensación de precisión

Estimación relativa (ágil)

En Agile, se estima comparando tareas entre sí. En lugar de decir "esto tomará 3 días", se dice "esto es el doble de complejo que aquella otra tarea que ya completamos".

Ventajas de la estimación relativa:

• Más intuitiva: Los humanos somos mejores comparando que midiendo en absoluto
• Menos presión: No genera compromisos de tiempo específicos
• Fomenta el consenso: Todo el equipo participa en la estimación
• Mejora con el tiempo: Se calibra automáticamente con la experiencia del equipo

Los puntos de historia son la unidad de medida más popular para la estimación ágil. Representan una combinación de tres factores:

1. Complejidad: ¿Qué tan difícil es técnicamente?
2. Esfuerzo: ¿Cuánto trabajo implica?
3. Incertidumbre: ¿Cuántas incógnitas hay?

La secuencia de Fibonacci

La mayoría de los equipos usan una secuencia basada en Fibonacci para asignar puntos de historia:

1, 2, 3, 5, 8, 13, 21

¿Por qué Fibonacci? Porque a medida que una tarea crece en tamaño, también crece la incertidumbre. Los saltos entre números reflejan que no tiene sentido distinguir entre una tarea de "14 puntos" y una de "15 puntos" cuando la incertidumbre es tan alta.

Ejemplo práctico

Imagina que tu equipo tiene estas tareas:

Planning Poker

Es la técnica de estimación más popular en equipos Scrum. Fue introducida por James Grenning en 2002 e impulsada por Mike Cohn a través de su libro Agile Estimating and Planning. Un estudio de Moloekken-Ostvold y Haugen (2007) publicado en Information and Software Technology encontró que el Planning Poker produce estimaciones un 47% más precisas que las estimaciones individuales de expertos.

1. El Product Owner presenta una historia de usuario
2. El equipo hace preguntas para clarificar la historia
3. Cada miembro del equipo selecciona una carta con su estimación (sin mostrarla)
4. Todos revelan sus cartas al mismo tiempo
5. Si hay diferencias significativas, las personas con las estimaciones más altas y más bajas explican su razonamiento
6. Se repite hasta alcanzar un consenso

¿Por qué revelar simultáneamente? Para evitar el efecto ancla (anchoring bias), un sesgo cognitivo documentado por Kahneman y Tversky en su investigación sobre juicio bajo incertidumbre (Science, 1974).

T-Shirt Sizing

Una técnica más rápida y menos formal que usa tallas de camiseta:

• XS: Tarea trivial (minutos)
• S: Tarea pequeña (horas)
• M: Tarea mediana (1-2 días)
• L: Tarea grande (varios días)
• XL: Tarea muy grande (debe descomponerse)

Es útil para estimaciones de alto nivel, como durante el refinamiento inicial del backlog o en sesiones de roadmap y sprint planning.

Dot Voting

Cada miembro del equipo tiene un número limitado de "puntos" que distribuye entre las historias según su percepción de complejidad. Es rápido pero menos preciso.

Affinity Mapping (Wall Estimation)

Se colocan todas las historias en una pared y el equipo las organiza en columnas según su tamaño relativo. Es excelente para estimar un backlog grande rápidamente.

Estimación por referencia

Se elige una historia de referencia (benchmark) bien conocida y se asigna un valor fijo. Las demás historias se estiman comparándolas con esta referencia.

Un principio fundamental de la estimación ágil es que el equipo completo estima, no solo el tech lead o el desarrollador senior:

• Desarrolladores: Aportan perspectiva técnica sobre complejidad e implementación
• Testers/QA: Identifican la complejidad del testing y posibles edge cases
• Diseñadores: Señalan complejidad en UX/UI que otros podrían pasar por alto
• Scrum Master: Facilita el proceso pero no estima (no es parte del equipo de desarrollo en Scrum)

La diversidad de perspectivas produce estimaciones más fiables y genera un entendimiento compartido del trabajo a realizar.

La velocity (velocidad) es la cantidad de puntos de historia que un equipo completa por sprint. Es el complemento natural de la estimación:

• Si un equipo tiene una velocity promedio de 30 puntos/sprint, puede planificar sprints con aproximadamente 30 puntos de trabajo
• La velocity se estabiliza después de 3-5 sprints, lo que permite hacer predicciones más fiables
• No es una métrica de productividad: Es una herramienta de planificación interna del equipo

Cómo usar la velocity

1. Registra los puntos completados en cada sprint
2. Calcula el promedio de los últimos 3-5 sprints
3. Usa ese promedio para planificar el siguiente sprint
4. Ajusta según circunstancias conocidas (vacaciones, cambios de equipo)

Existe un debate activo en la comunidad ágil sobre si las estimaciones son necesarias. El movimiento #NoEstimates, impulsado por profesionales como Woody Zuill y Vasco Duarte (autor de NoEstimates, Oikosofy, 2016), propone:

• En lugar de estimar, hacer los ítems lo más pequeños posible para que tengan un tamaño similar
• Usar el throughput (ítems completados por período) en lugar de velocity
• Predecir con simulaciones Monte Carlo basadas en datos históricos
• El tiempo dedicado a estimar podría usarse mejor en desarrollar

¿Cuándo tiene sentido no estimar?

• Equipos muy maduros con ítems de tamaño consistente
• Flujos Kanban con datos históricos suficientes
• Cuando el coste de estimar supera el beneficio de la información obtenida

¿Cuándo las estimaciones siguen siendo útiles?

• Equipos nuevos que necesitan calibrarse
• Cuando los stakeholders necesitan fechas aproximadas
• Para identificar historias demasiado grandes que deben descomponerse
• Cuando el Product Owner necesita evaluar el ROI de diferentes features

1. Estima en equipo: Nunca dejes que una sola persona estime por todos
2. No conviertas puntos en horas: Los puntos de historia no son una unidad de tiempo disfrazada
3. Reestima si la información cambia: Si descubres nueva complejidad, actualiza la estimación
4. No uses la velocity para comparar equipos: Cada equipo tiene su propia escala
5. Descompón lo grande: Si una historia supera los 13 puntos, probablemente necesita dividirse
6. Acepta la incertidumbre: Las estimaciones son estimaciones, no promesas
7. Revisa y aprende: Compara estimaciones con el esfuerzo real en las retrospectivas

• Estimación por presión: Reducir la estimación porque "no hay tiempo" no cambia la realidad del trabajo
• Efecto ancla: Dejarse influir por la primera estimación que se escucha
• Sesgo de optimismo: Estimar solo el "happy path" sin considerar testing, edge cases o deuda técnica
• Estimación individual: Que solo una persona decida el tamaño de las historias
• Obsesión con la precisión: Dedicar 30 minutos a debatir si una historia es un 5 o un 8

¿Cuánto tiempo debe dedicarse a estimar?

Como regla general, el refinamiento (que incluye estimación) no debería consumir más del 10% del tiempo del sprint. En un sprint de 2 semanas, eso son unas 4 horas en total.

¿Qué hacer cuando el equipo no se pone de acuerdo?

Discutir las diferencias es valioso: revela supuestos ocultos y distintas interpretaciones del trabajo. Si tras dos rondas no hay consenso, se suele tomar la estimación más alta como medida de precaución.

¿Se deben estimar los bugs?

Depende del equipo. Algunos equipos estiman bugs para incluirlos en la velocity, otros no los estiman y los tratan como "overhead" del sprint. Lo importante es ser consistente.

¿Cómo estimar cuando el equipo es nuevo?

Se recomienda empezar con una historia de referencia bien entendida, asignarle un valor medio (como 3 o 5), y estimar las demás comparándolas con esa referencia. La calibración mejora sprint a sprint.

¿Los puntos de historia incluyen el testing?

Sí. Los puntos de historia deben reflejar todo el esfuerzo necesario para llevar una historia a "Done", incluyendo desarrollo, code review, testing, documentación y cualquier otra actividad requerida por la Definition of Done del equipo.