Estimación en XP

Los humanos somos malos estimando tiempo absoluto. "Esto tomará 3 días" casi siempre está mal. Subestimamos la complejidad y sobreestimamos nuestra productividad.

Pero los humanos somos buenos en comparación relativa. "Esta historia es aproximadamente el doble de grande que aquella" es algo que podemos hacer de manera confiable.

XP utiliza estimación relativa. En lugar de estimar horas, estimamos tamaño. Una historia puede ser un "2" o un "5" o un "13". Estos números no significan horas o días—significan tamaño relativo comparado con otras historias.

Por qué funciona lo relativo:

• Estamos comparando cosas que entendemos (historia con historia, no historia con tiempo)
• Es más rápido (no necesitas desglose detallado de tareas)
• Es más honesto (sin falsa precisión)
• Se autocorrige mediante el seguimiento de velocidad

Los puntos de historia son la unidad más común para estimación relativa.

Los puntos representan esfuerzo, complejidad e incertidumbre combinados—no tiempo. Una historia de 5 puntos es aproximadamente el doble del esfuerzo de una historia de 2 puntos (más o menos), pero no necesariamente el doble de horas.

Escalas de puntos comunes:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, ? (las brechas te obligan a elegir)
• Potencias de 2: 1, 2, 4, 8, 16 (duplicación simple)
• Tallas de camiseta: XS, S, M, L, XL (no numérico, bueno para planificación de alto nivel)

Consejos para asignar puntos a historias:

• Compara con historias de referencia ("¿Es esto más grande o más pequeño que la Historia X?")
• No lo pienses demasiado (los puntos son difusos por diseño)
• Incluye la incertidumbre en la estimación (desconocido = más grande)
• Re-estima si aprendes algo que cambia tu comprensión

Planning Poker es una técnica para alcanzar consenso del equipo en las estimaciones.

Cómo funciona:

1. El propietario del producto lee una historia
2. Los miembros del equipo hacen preguntas aclaratorias
3. Todos seleccionan privadamente una carta de estimación
4. Todas las cartas se revelan simultáneamente
5. Los estimadores más altos y más bajos explican su razonamiento
6. El equipo discute y vuelve a votar si es necesario
7. Emerge el consenso (o se toma el promedio)

¿Por qué revelación simultánea? Para prevenir el anclaje. Si el desarrollador senior dice "5" primero, todos los demás se ajustan hacia 5. Revelar simultáneamente captura opiniones independientes.

¿Por qué discutir valores atípicos? La persona que dijo "13" podría saber algo que otros no ("esto requiere migración de base de datos"). La persona que dijo "2" podría tener un enfoque más simple. Ambas perspectivas mejoran la estimación.

Planning Poker trata tanto de construir entendimiento compartido como de obtener un número. La discusión saca a la luz suposiciones, riesgos y decisiones de diseño.

Velocidad es cuántos puntos completa el equipo por iteración. Es la clave para convertir estimaciones relativas en predicciones.

Si el equipo completó 30 puntos la iteración pasada, probablemente completará alrededor de 30 puntos la próxima iteración. Esto se llama el clima de ayer—el mejor predictor del clima de mañana es el clima de hoy.

Usando la velocidad:

• Si tienes 100 puntos de trabajo y una velocidad de 20, espera alrededor de 5 iteraciones
• Si el cliente quiere lanzar en 3 iteraciones, puedes hacer alrededor de 60 puntos de trabajo
• La velocidad fluctúa; usa un promedio móvil (últimas 3-5 iteraciones)

Qué afecta la velocidad:

• Composición del equipo (vacaciones, nuevos miembros)
• Entorno técnico (nuevo framework, cambios de infraestructura)
• Tipo de trabajo (nueva funcionalidad vs corrección de bugs)
• Enfoque del equipo (las interrupciones matan la velocidad)

No manipules la velocidad. No es una métrica de productividad—es una herramienta de planificación. Inflar puntos o tomar atajos para "aumentar la velocidad" derrota el propósito.

Las estimaciones son suposiciones. Estarán equivocadas. XP reconoce esto y construye adaptabilidad.

Fallas comunes de estimación:

• Desconocidos desconocidos: Emerge complejidad imprevista
• Dependencias: Equipos o sistemas externos causan retrasos
• Expansión del alcance: La historia crece mientras la construyes
• Deuda técnica: El código existente es más difícil de cambiar de lo esperado

Qué hacer cuando estás fuera de curso:

1. Hazlo visible inmediatamente (transparencia)
2. Re-estima basándote en el nuevo entendimiento
3. Discute con el propietario del producto
4. Negocia el alcance si es necesario (incremento más pequeño, diferir funcionalidades)

No lo ocultes. No trabajes horas extra para cumplir una mala estimación. El punto completo de la estimación es planificar—si el plan está mal, cámbialo.

Con el tiempo, las estimaciones mejoran. A medida que el equipo gana experiencia con el código base y entre sí, la incertidumbre disminuye. Pero nunca serán perfectas—por eso XP enfatiza la adaptación sobre la predicción.