Estimación relativa: la idea detrás de toda técnica ágil

La estimación relativa dimensiona el trabajo comparándolo con otro trabajo ("¿esto es más grande o más pequeño que X?") en lugar de predecir cuánto tiempo tomará en horas o días. Cada técnica de la guía completa de estimación ágil (Scrum Poker, t-shirt sizing, estimación por afinidad) es una forma estructurada de producir esa comparación en grupo. Esta página cubre la idea en sí misma: por qué funciona, dónde se rompe, y un ejemplo trabajado que no requiere ningún trasfondo de software para seguirlo.

La idea central, sin nada de software

Imagina dimensionar tres tareas: colgar un cuadro, instalar una puerta, construir una casa. Nadie necesita experiencia en construcción para ordenarlas por esfuerzo: cuadro, puerta, casa, en ese orden, con brechas cada vez mayores entre ellas. La mayoría de las personas también podrían decir que la brecha entre "puerta" y "casa" es mucho mayor que la brecha entre "cuadro" y "puerta", incluso sin saber exactamente cuántas horas toma cada trabajo.

Ese orden, confiable, rápido, sin requerir experiencia en el dominio más allá del sentido común, es estimación relativa. Los equipos de software hacen lo mismo con los elementos del backlog: "¿esta historia es más grande o más pequeña que el formulario de inicio de sesión que construimos el sprint pasado?" es una pregunta que la mayoría de los miembros del equipo puede responder con confianza, incluso cuando "¿cuántas horas tomará esto?" produce suposiciones muy distintas de las mismas personas.

Por qué las comparaciones relativas superan a las suposiciones absolutas

Esto no es una preferencia: es una limitación humana documentada. Las personas son consistentemente malas prediciendo duraciones absolutas para trabajo desconocido, pero consistentemente buenas comparando. La investigación detrás de esto (gran parte de Magne Jørgensen y colegas estudiando específicamente la estimación de software) muestra el mismo patrón en distintos dominios: pregúntale a alguien "cuánto tiempo tomará esto" y obtienes una suposición con exceso de confianza y anclada; pregunta "¿esto es más grande que aquello?" y obtienes una respuesta mucho más confiable.

El ejemplo del cuadro/puerta/casa lo hace intuitivo: pídele a alguien que estime horas para construir una casa desde cero, sin experiencia en construcción, y el número está cerca de ser sin sentido. Pídele a la misma persona si una casa toma más tiempo en construirse que una puerta, y lo acertará siempre, al instante.

Cómo esto se convierte en una técnica de equipo

El juicio relativo de una sola persona es útil; el juicio relativo compartido de un equipo, conciliado a través de una breve discusión, es aún más confiable. Este es el mecanismo real detrás de Scrum Poker: cada persona vota su propio juicio de tamaño relativo en privado, la revelación muestra dónde divergen esos juicios, y la discusión posterior expone exactamente por qué la comparación de una persona difiere de la de otra, a menudo porque una persona sabe algo sobre el trabajo que las demás no saben.

Distintas técnicas usan distintas escalas para la misma comparación subyacente:

• Puntos Fibonacci (0, 1, 2, 3, 5, 8, 13, 21): numéricos, suman a una cifra de velocidad. Ver puntos de historia.
• Tallas de camiseta (XS-XXL): categóricas, más rápidas, no suman sin un mapeo. Ver t-shirt sizing.
• Agrupación por afinidad: puramente espacial/visual, sin números en absoluto hasta un paso de mapeo posterior. Ver estimación por afinidad.

Las tres son estimación relativa con distinta ropa. La elección entre ellas es sobre velocidad, precisión y audiencia, no sobre cuál es "más correcta", porque ninguna afirma predecir la duración absoluta en primer lugar.

Una comparación trabajada, de varias formas

Toma tres elementos del backlog: agregar un tooltip, agregar un filtro de búsqueda, reconstruir el flujo de pago.

• Solo orden relativo: tooltip < filtro de búsqueda < reconstrucción de pago. Obvio para casi cualquiera del equipo, técnico o no.
• Puntos Fibonacci: tooltip = 1, filtro de búsqueda = 3, reconstrucción de pago = 13. El equipo ahora también ha expresado cuánto más grande, no solo el orden.
• Tallas de camiseta: tooltip = XS, filtro de búsqueda = S, reconstrucción de pago = XL. Más rápido de acordar que puntos exactos, menos preciso sobre el tamaño de la brecha.

Cada versión codifica el mismo juicio relativo subyacente. Lo que cambia es la precisión y la velocidad, no la comparación fundamental que se está haciendo.

Dónde falla la estimación relativa

Cuando aún no hay nada con qué comparar. Un equipo completamente nuevo sin historias completadas no tiene punto de referencia; las primeras estimaciones relativas están más cerca de ser arbitrarias que calibradas, porque "¿más grande o más pequeño que qué?" todavía no tiene una buena respuesta. Por eso los equipos nuevos tardan algunos sprints en calibrarse antes de que sus puntos signifiquen algo.

Cuando un interesado necesita una fecha real, no un orden. La estimación relativa te da orden y magnitud aproximada, no un calendario. Convertir una estimación relativa en un cronograma requiere un paso adicional, generalmente la velocidad (puntos completados por sprint, históricamente) o, para una estimación grande y única, la estimación de tres puntos, que es deliberadamente absoluta en lugar de relativa.

Cuando los equipos se comparan entre sí. Las estimaciones relativas están calibradas contra los propios puntos de referencia de un equipo; "nuestro 5" y "su 5" describen cantidades de trabajo distintas, porque el conjunto de comparación es diferente. Los puntos de historia no se transfieren entre equipos por esta misma razón.

Ponlo en práctica

La forma más rápida de sentir por qué funcionan las comparaciones relativas es ejecutar una sesión real. Crea una sala gratis, elige cinco historias de un backlog real, y observa cuánto más rápido converge el equipo en "¿esto es más grande que aquello?" comparado con "¿cuántas horas, exactamente?".