Estimación de tres puntos (PERT)
La estimación de tres puntos pide tres números en lugar de uno (optimista, más probable y pesimista) y los combina en un valor esperado ponderado con un rango de confianza incorporado. Es la excepción dentro de la familia de técnicas de estimación ágil: cada otra técnica de la guía completa es relativa (comparar trabajo con otro trabajo); tres puntos es absoluta (predice la duración o el esfuerzo real). Esta página cubre cómo funciona, cuándo es la herramienta adecuada, y cuándo no lo es.
La fórmula
Cada estimador proporciona:
- Optimista (O): el mejor caso, todo sale bien
- Más probable (M): lo que honestamente esperarías
- Pesimista (P): el peor caso, aparecen problemas reales
Valor esperado = (O + 4M + P) / 6
El caso más probable cuenta cuatro veces más que cualquiera de los extremos, por lo que el resultado se inclina hacia lo que normalmente esperarías en lugar de dividir la diferencia entre el mejor y el peor caso. La dispersión entre optimista y pesimista también produce una desviación estándar, (P − O) / 6, dando a la estimación un rango de confianza explícito en lugar de un número presentado como certeza. Calcula tus propios números: calculadora PERT / de tres puntos.
De dónde viene esta técnica
La estimación de tres puntos es el análisis PERT (Program Evaluation and Review Technique), desarrollado para el programa de misiles Polaris de la Marina de los EE. UU. a finales de la década de 1950 para estimar cronogramas de proyectos bajo incertidumbre genuina. Precede a la estimación ágil de software por décadas y sigue siendo estándar en la gestión de proyectos tradicional, por lo que aparece en contextos ágiles principalmente en el límite donde la estimación de software tiene que dialogar con un cronograma.
Cuándo la estimación de tres puntos es la herramienta correcta
Un interesado necesita un cronograma con un rango de confianza, no un plan a nivel de historia. "Esta épica probablemente tomará 6 semanas, con un rango realista de 4 a 9" es una frase genuinamente útil para una conversación de roadmap: se compromete con menos falsa precisión que una estimación puntual única mientras sigue siendo utilizable para planificar.
Estimar piezas grandes de trabajo (épicas, funcionalidades, trimestres) en lugar de historias listas para el sprint. La estimación de tres puntos es más lenta por elemento que Scrum Poker, así que no escala al dimensionamiento historia por historia a nivel de sprint. Se ajusta al puñado de estimaciones grandes y de alto riesgo que un trimestre realmente necesita, no a las docenas de estimaciones pequeñas que necesita un sprint.
La audiencia está acostumbrada a cronogramas, no a puntos de historia. Un número expresado en semanas o días, con un rango de confianza declarado, comunica a un interesado no técnico de una manera que "34 puntos de historia" simplemente no logra.
Cuándo no lo es
Dimensionamiento de historias a nivel de sprint. Ejecutar estimación de tres puntos en cada elemento del backlog anula su propio propósito: es más lenta que Scrum Poker por elemento y produce una salida matemáticamente promediada en lugar de un consenso de equipo, que es exactamente lo que la estimación grupal a través de la discusión intenta capturar. Comparación completa: estimación de tres puntos vs. planning poker.
Cuando el equipo necesita un número de velocidad. Las salidas de tres puntos alimentan cálculos de cronograma, no puntos por sprint. Si el objetivo es rastrear la tasa de entrega de un equipo a lo largo del tiempo, los puntos de historia y la velocidad son la unidad correcta, no un valor esperado de PERT.
Cuando "más probable" en realidad es solo una suposición. La fórmula solo produce algo significativo si las tres entradas reflejan un juicio real sobre el trabajo. Tres números que suenan confiados para un trabajo que nadie entiende todavía solo producen falsa precisión con matemática adicional; una investigación previa para reducir la incertidumbre real es el mejor movimiento primero.
Un ejemplo trabajado
Un equipo necesita estimar "migrar el servicio de reportes al nuevo data warehouse" para un interesado que quiere un compromiso de cronograma, no un plan a nivel de sprint.
- Optimista: 3 semanas, si el mapeo del esquema resulta ser mayormente mecánico.
- Más probable: 5 semanas, según cómo han ido migraciones similares antes.
- Pesimista: 10 semanas, si los límites de tasa del warehouse obligan a un enfoque de migración más lento y por lotes.
Valor esperado = (3 + 4×5 + 10) / 6 = 33 / 6 ≈ 5.5 semanas
Desviación estándar = (10 − 3) / 6 ≈ 1.2 semanas
El equipo comunica esto como "alrededor de 5.5 semanas, con un rango realista de aproximadamente 4.3 a 6.7 semanas", un número que es honesto sobre la incertidumbre en lugar de comprometerse con una fecha única que el caso pesimista podría superar.
La estimación de tres puntos y el cono de incertidumbre
Esta técnica tiene más sentido usada en el punto de el cono de incertidumbre donde una pieza de trabajo se entiende lo suficientemente bien como para acotar los casos optimista y pesimista de forma significativa, pero no tan bien entendida como para ya estar dividida en historias listas para el sprint. Demasiado pronto, y las tres entradas son suposiciones; demasiado tarde, y el trabajo ya debería estar en rondas de Scrum Poker a nivel de historia.
Calcula tu propia estimación
Salta la matemática manual: la calculadora PERT / de tres puntos toma tus tres entradas y devuelve al instante el valor esperado y el rango de confianza.