"How long do you think the migration will take?"
La pregunta llega en el standup, sin aviso. Decir "two weeks" se siente más seguro que decir "I'm not sure yet" — así que lo dices. Tres semanas después, esas dos palabras son la fecha que el PM puso en el roadmap, la que tu manager repitió en la reunión con el VP, la que ahora tienes que defender aunque nunca fue una promesa.
El error más común: dar un número puntual o esquivar la pregunta
Frente a una pregunta de estimación en inglés, el Tech Lead cae en uno de dos extremos. El primero da un número exacto sin condiciones — "two weeks" — que la sala escucha como compromiso, no como estimación. El segundo esquiva la pregunta — "it's hard to say", "it depends" — sin agregar qué es lo que depende, y la sala lee eso como que no lo pensó todavía.
Ninguno de los dos transmite lo que en realidad tienes: un rango con condiciones conocidas. El número puntual promete más de lo que sabes. El "depende" sin especificar comunica menos de lo que sabes.
La consecuencia no aparece el día de la estimación — aparece seis semanas después, cuando "two weeks" ya viajó por tres reuniones sin las condiciones que tenías en la cabeza cuando lo dijiste. Para entonces, el retraso se lee como una falla de ejecución. Nunca se lee como lo que fue: un supuesto que nadie escribió.
El framework en 4 pasos: Rango → Supuesto → Riesgo → Checkpoint
Paso 1: Da un rango, no un número puntual
El rango comunica honestidad sin sonar evasivo, siempre que tenga límites concretos.
Di: "Somewhere between three and five weeks."
No digas: "Two weeks." ni "Hard to say."
Un rango de dos extremos es información. Un número puntual es una apuesta. Un "depende" sin rango es silencio con palabras.
Paso 2: Nombra el supuesto detrás del rango
El rango sin supuesto es tan frágil como el número puntual — nadie sabe qué lo movería.
Di: "That's assuming the schema doesn't need to change."
No digas: "It depends on a few things."
Un supuesto nombrado le dice a la sala exactamente qué pregunta hacer si quiere presionar el número hacia abajo.
Paso 3: Flaggea el riesgo más grande que podría romper el rango
No todos los riesgos importan igual. Nombra el que de verdad puede sacar la estimación del rango.
Di: "The biggest unknown is how the auth service handles the migration — if it needs a rewrite, that adds two to three weeks."
No digas: "There are some risks."
Paso 4: Ofrece un checkpoint donde el número se ajusta
Cierra explicando cuándo vas a tener más certeza, no prometiendo que el rango no va a cambiar.
Di: "I can give you a tighter number after we spike on the auth service for two days."
Esto convierte la estimación en un proceso visible, no en una cifra fija que alguien archivó y va a citar en tres meses.
Cuando presionan por el extremo más bajo del rango
Casi siempre alguien va a preguntar si el rango puede ser más ajustado — "could this be closer to three weeks than five?" La respuesta que funciona no es defender el rango completo de nuevo, es volver al supuesto específico que determina qué extremo aplica.
Di: "It's three if the auth service doesn't need changes — that's the one thing I can't confirm without the spike."
No digas: "Maybe, we'll see."
Esto mantiene el rango intacto sin que la conversación se sienta como una negociación de precio.
Ejemplos de diálogo real
Escenario: pregunta de estimación en standup
PM: "How long do you think the migration will take?"
"Somewhere between three and five weeks, assuming the schema doesn't need to change. The biggest unknown is the auth service — if it needs a rewrite, that adds two to three weeks. I can give you a tighter number after we spike on that for two days."
Cuatro frases. Un rango, un supuesto, un riesgo cuantificado, un checkpoint concreto.
Escenario: el stakeholder solo quiere un número para el roadmap
Stakeholder: "I need one number to put on the roadmap — can you just give me a date?"
"If you need one number, use five weeks — that's the safe end. It could be three if the schema stays stable, and I'll know for sure after the spike on Thursday."
Dar el extremo superior como el número "seguro" resuelve la necesidad de planificación del stakeholder sin que el Tech Lead termine defendiendo una fecha optimista que nunca calificó.
Escenario: hay que actualizar una estimación ya comunicada
"Quick update on the migration estimate — it assumed the schema was stable, and it isn't. The range moves to six to eight weeks. The auth service is the same risk as before, so I'll have a tighter number after Thursday's spike."
Conectar el ajuste con el supuesto que cambió, no con una disculpa, mantiene la conversación en los hechos. Un supuesto que cambió es información nueva. Un "sorry, this is taking longer than expected" es una admisión sin datos detrás.
Qué practicar esta semana
Antes de tu próxima estimación en inglés, arma las cuatro frases con tu situación real:
- "Somewhere between [X] and [Y]."
- "That's assuming [supuesto]."
- "The biggest unknown is [riesgo] — if it happens, that adds [impacto]."
- "I'll have a tighter number after [checkpoint concreto]."
Si puedes completar las cuatro frases antes de que te hagan la pregunta en el standup, la estimación deja de ser un número que te persigue durante meses y empieza a ser información que la sala puede usar para planear.