Para Qué Sirve la Estimación

La estimación hace tres trabajos, y los equipos que los confunden terminan frustrados con los tres.

Trabajo 1: Entendimiento compartido. Cuando un equipo estima un ticket juntos, el número es un efecto secundario. El resultado real es la conversación. Un ingeniero dice "ese es un cambio pequeño — cambiar el endpoint y actualizar las pruebas". Otro dice "espera, ese endpoint está detrás de un feature flag del que dependen otros tres servicios". La brecha entre sus estimaciones es la brecha entre sus modelos mentales del trabajo. Sacar a la luz esa brecha antes de que comience el trabajo vale más que el número.

Trabajo 2: Planificación de capacidad. Un equipo con 10 ingenieros y un sprint de dos semanas tiene una cantidad finita de trabajo que puede absorber. La estimación — incluso la estimación aproximada — te dice si estás cargando el 80% de la capacidad o el 140%. Sin ella, la planificación del sprint es adivinar, y "nos comprometimos con demasiado" se convierte en un tema recurrente de retrospectiva.

Trabajo 3: Priorización. Una funcionalidad que entrega valor moderado y cuesta un esfuerzo pequeño es una conversación diferente que una funcionalidad que entrega el mismo valor y cuesta un esfuerzo grande. La estimación le da a producto e ingeniería un lenguaje compartido para hacer intercambios. Sin ella, la priorización se reduce a quien argumente más fuerte.

Algunos trabajos genuinamente no se pueden estimar, y pretender lo contrario produce números que engañan más de lo que informan.

Un ticket que dice "investigar por qué el webhook de pagos falla intermitentemente" no es estimable. El ingeniero no sabe si la causa raíz es una condición de carrera, un timeout de API de terceros, una política de reintentos mal configurada o algo completamente diferente. Estimarlo como "mediano" solo asigna un número a la ignorancia — y ahora el plan del sprint trata ese número como si significara algo.

La respuesta honesta es "no sé, y necesito un spike para averiguarlo". Un spike es una investigación con tiempo limitado — típicamente de medio día a dos días — cuyo resultado no es código funcional sino información. Después del spike, el equipo sabe lo suficiente para estimar la corrección real. Los spikes no son un fracaso de la estimación; son la estimación funcionando correctamente al admitir sus propios límites.

Lo mismo aplica para trabajo genuinamente novedoso: una nueva integración con una API desconocida, una migración a una tecnología que el equipo no ha usado, o un problema de rendimiento sin cuello de botella obvio. Forzar una estimación en estos tickets no produce información útil — produce un número que el equipo se siente obligado a cumplir y un plan construido sobre ficción.

Los equipos que se obsesionan con la precisión de la estimación están optimizando lo incorrecto. Un equipo cuyas estimaciones están consistentemente desviadas en un 30% pero que usa la conversación de estimación para sacar a la luz suposiciones, detectar brechas de alcance y alinearse en el enfoque está obteniendo más valor de la estimación que un equipo cuyos números caen perfectamente pero que estima en silencio.

El número es un subproducto. La conversación es el producto. Cuando dos ingenieros estiman el mismo ticket de manera diferente, ese desacuerdo es información — uno de ellos sabe algo que el otro no, o están imaginando implementaciones diferentes. Resolver ese desacuerdo antes de que comience el trabajo previene retrabajo, detecta requisitos faltantes y construye contexto compartido en todo el equipo.

Por eso los métodos de estimación que fuerzan la conversación (como Planning Poker, donde todos revelan simultáneamente) superan a los métodos que no lo hacen (como una persona anunciando un número y preguntando "¿suena bien?"). La revelación no es sobre el número — es sobre la brecha. Un ticket donde todos muestran un 3 es aburrido. Un ticket donde una persona muestra un 2 y otra muestra un 8 es donde la estimación gana su valor.