Honesto sobre los límites.
Una estimación es un pronóstico, no un contrato. En el momento en que un equipo trata una estimación como un compromiso — "dijiste que era un 5, así que debería estar listo para el miércoles" — la estimación deja de ser una herramienta de planificación y se convierte en un mecanismo de castigo. Los ingenieros responden inflando las estimaciones para protegerse, lo que hace que las estimaciones sean inútiles para la planificación, lo que hace que los stakeholders presionen más por números "precisos", lo que hace que los ingenieros inflen más. El ciclo es predecible y común.
La distinción importa más en el límite entre ingeniería y el resto de la organización. Dentro del equipo, las estimaciones impulsan la capacidad del sprint y ayudan a identificar semanas sobrecargadas. Eso está bien — el equipo controla el plan y puede ajustarlo a mitad del sprint. El problema comienza cuando las estimaciones salen del equipo como promesas de entrega a ventas, ejecutivos o clientes. Un "creemos que esto es aproximadamente 13 puntos de trabajo" se convierte en "ingeniería se comprometió a tres semanas" en una presentación que el equipo nunca ve.
Proteger las estimaciones de convertirse en compromisos es una disciplina del equipo y una responsabilidad del liderazgo. El equipo debe comunicar las estimaciones como rangos ("2–4 semanas dependiendo de lo que encontremos en el código legacy"), no puntos. Y los líderes deben resistir la presión de eliminar la incertidumbre de las estimaciones para que una hoja de ruta se vea más limpia. La incertidumbre es la parte honesta.
La estimación tiene un costo: el tiempo que el equipo pasa estimando en lugar de construir. Para la mayoría de los equipos, ese costo es razonable — 30 minutos de estimación ahorran horas de sorpresas a mitad del sprint. Pero el costo puede crecer hasta que la ceremonia consuma más valor del que produce.
Señales de advertencia de que la estimación se ha convertido en su propio desperdicio:
El principio es el mismo que se aplica a cada pieza de proceso: si no está creando apalancamiento, está creando sobrecarga. La estimación debe ser barata, rápida y útil. Cuando se vuelve costosa, lenta o ignorada, redúcela.
El movimiento #NoEstimates argumenta que la estimación es a menudo innecesaria y que los equipos pueden pronosticar la entrega usando rendimiento histórico — el número de tickets completados por semana — en lugar de asignar tamaños a tickets individuales. El argumento tiene mérito, y descartarlo como pereza es tan incorrecto como tratarlo como un evangelio.
El pronóstico basado en rendimiento funciona así: si un equipo completa consistentemente 10–14 tickets por semana, y un proyecto tiene 45 tickets, el pronóstico es 3–5 semanas. No se necesita sesión de estimación. Las matemáticas dependen de dos condiciones: los tickets necesitan ser divididos en tamaños aproximadamente similares, y el equipo necesita suficientes datos históricos para establecer un rango de rendimiento confiable. Cuando se cumplen esas condiciones, el pronóstico es a menudo más preciso que una estimación de abajo hacia arriba de cada ticket individual.
El problema es la disciplina. Los equipos que omiten la estimación pero también omiten la disciplina de división terminan sin ninguna capacidad de pronóstico — no pueden estimar porque han abandonado la práctica, y no pueden usar el rendimiento porque sus tickets van desde arreglos de una hora hasta épicas de tres semanas. #NoEstimates sin división consistente es simplemente #NoInformation.
Para la mayoría de los equipos, el camino pragmático está en algún punto intermedio: estimar ligeramente (S/M/L), rastrear el rendimiento como una señal secundaria, y abandonar la estimación por completo solo cuando los datos muestren que el rendimiento solo es suficiente. La peor elección es estimar mucho e ignorar el rendimiento — eso es ceremonia máxima para información mínima.
La opción #NoEstimates
Algunos equipos maduros abandonan la estimación por completo y usan el rendimiento (conteo de elementos completados por semana) para pronosticar. Funciona — pero solo cuando el equipo tiene la disciplina para dividir el trabajo uniformemente.