La Estimación Mínima Útil

La mayoría de los equipos sobreinvierten en precisión de estimación. Debaten durante diez minutos si un ticket es un 5 o un 8 — una distinción que no tiene ningún impacto en la planificación del sprint y aún menos en la entrega. El tiempo que se pasa discutiendo sobre granularidad es tiempo que no se dedica a entender el trabajo.

Tres tamaños — pequeño, mediano, grande — cubren la gran mayoría de las necesidades de planificación. Un ticket pequeño es trabajo bien entendido que un ingeniero puede terminar en un día o menos. Un mediano es de un día a tres días con algo de complejidad o incógnitas. Un grande es más de tres días y probablemente necesita dividirse antes de que alguien comience.

Eso es todo. Si tu equipo puede clasificar tickets en esos tres grupos de manera consistente, tienes suficiente información para planificar un sprint, detectar semanas sobrecargadas e identificar tickets que necesitan más discusión. El valor marginal de dividir "mediano" en 3, 5 y 8 es real para algunos equipos — pero la mayoría de los equipos no lo necesitan, y la complejidad cuesta más que las ganancias en precisión.

Comienza con S/M/L. Si después de algunos sprints encuentras que tu planificación necesita consistentemente una resolución más fina — tal vez los tickets grandes varían demasiado, o estás haciendo compromisos externos que necesitan pronósticos más ajustados — actualiza a Fibonacci o tallas de camiseta. Pero haz que sea una decisión basada en evidencia, no una decisión basada en lo que un framework te dijo que hicieras.

S/M/L falla cuando alguien fuera del equipo necesita más que "aproximadamente cuánto trabajo es esto?" Tres situaciones te empujan hacia una estimación más granular:

Compromisos externos. Cuando un equipo de ventas necesita decirle a un cliente "la función X se lanzará en el tercer trimestre," el equipo de ingeniería necesita estimar con suficiente resolución para respaldar esa fecha. S/M/L no puede distinguir entre "tres semanas" y "tres meses." Las estimaciones en escala Fibonacci combinadas con datos históricos de velocidad pueden hacerlo — no perfectamente, pero lo suficientemente bien como para dar un rango en lugar de encogerse de hombros.

Presupuesto y dotación de personal. Un equipo de producto que decide si financiar el Proyecto A o el Proyecto B necesita comparar sus costos. "El Proyecto A es 40 puntos de historia y el Proyecto B es 90" es una entrada aproximada pero útil. "El Proyecto A tiene algunos medianos y el Proyecto B tiene más grandes" no lo es.

Planificación de dependencias. Cuando el trabajo del Equipo A está bloqueado hasta que el Equipo B termine un prerrequisito, ambos equipos necesitan suficiente precisión de estimación para coordinar cronogramas. "Terminaremos en algún momento en los próximos uno o dos sprints" no es suficiente cuando un equipo posterior está programando su trabajo en torno a la entrega.

En los tres casos, la inversión en precisión se paga a sí misma porque alguien está tomando una decisión basada en la estimación. Si nadie está tomando una decisión — si las estimaciones van a un rastreador y nadie las mira — ahorra el tiempo.

La mayor amenaza para la estimación honesta es el anclaje: el primer número dicho en voz alta distorsiona cada número que sigue. Si el líder técnico dice "creo que eso es aproximadamente un 3," el ingeniero junior que estaba pensando en 8 se cuestiona a sí mismo y dice 5. El equipo converge en un número que refleja la voz más fuerte, no el entendimiento colectivo.

Planning Poker resuelve esto mecánicamente. Todos estiman simultáneamente y revelan al mismo tiempo. No hay anclaje porque no hay un primer número. La dispersión — la brecha entre la estimación más alta y la más baja — es la señal. Un 3 unánime significa que el equipo está de acuerdo y sigues adelante. Una división entre 2 y 13 significa que dos personas están imaginando trabajos fundamentalmente diferentes, y esa conversación necesita ocurrir antes de que alguien escriba código.

La estimación asíncrona extiende esto a equipos distribuidos. En lugar de reunirse en una sala, los ingenieros envían estimaciones de forma independiente durante una ventana de tiempo, con votos ocultos hasta que todos hayan enviado. El beneficio anti-anclaje es el mismo; la logística se ajusta a equipos que abarcan zonas horarias o no pueden justificar reuniones sincrónicas para cada lote de tickets.

Ambos enfoques comparten el mismo principio: la estimación funciona mejor cuando las opiniones se forman independientemente antes de compartirse. Cualquier método que permita que el número del ingeniero senior influya en la sala antes de que otros se hayan comprometido con su propia estimación está dejando información sobre la mesa.