Qué es la escala de Evans: Desvelando el secreto de la estimación ágil en tus proyectos

Table of Contents

Qué es la escala de Evans: Un enfoque humano para la estimación de proyectos

Imagina esta situación: eres Juan, un jefe de proyecto con años de experiencia, y tu equipo se encuentra en plena fase de planificación. Tienes una lista de tareas por delante, y la pregunta del millón, como siempre, es: «¿Cuánto tiempo o esfuerzo nos llevará hacer todo esto?». Las estimaciones individuales varían una barbaridad, desde «pan comido» hasta «esto es una locura, no hay por dónde cogerlo». Los debates se eternizan, la frustración crece y, al final, las estimaciones son poco más que un tiro al aire. Vaya, qué lío, ¿verdad?

Pues bien, Juan, y tú, querido lector, no estáis solos. Esta es una escena común en muchos equipos. La estimación de tareas, especialmente aquellas con un alto grado de incertidumbre o complejidad, puede convertirse en un verdadero quebradero de cabeza. Aquí es donde entra en juego una herramienta que, para muchos, ha sido un antes y un después: la escala de Evans. ¿Qué es la escala de Evans? En esencia, es un conjunto de valores numéricos, a menudo inspirados en la secuencia de Fibonacci, que se utiliza para cuantificar la incertidumbre, el riesgo y el esfuerzo relativo de una tarea, fomentando la discusión y el consenso en el equipo. No es solo un número; es una conversación que te revela mucho más de lo que esperas.

Esta escala, popularizada en entornos de desarrollo ágil como Scrum a través de técnicas como el Planning Poker, se ha convertido en un pilar fundamental para equipos que buscan mejorar la precisión de sus estimaciones y, lo que es aún más importante, la comprensión compartida de lo que implican las tareas. Permite pasar de un «creo que tardaré tres días» —que puede ser un puro deseo— a una estimación colectiva que refleja la complejidad inherente, las incógnitas y el esfuerzo percibido por todo el equipo. Es una joya para desentrañar lo que se esconde detrás de cada tarea y asegurar que todos estén en la misma página.

El Corazón de la Escala de Evans: Más Allá de los Números Aleatorios

La escala de Evans no se inventó de la noche a la mañana ni con números al azar. Se basa en una lógica que refleja cómo los seres humanos percibimos la complejidad. A menudo, utiliza una secuencia similar a la de Fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, y a veces, valores especiales como «infinito» (∞) o un signo de interrogación (?). Pero, ¿por qué esta secuencia tan particular y no, digamos, una escala lineal como 1, 2, 3, 4, 5…?

La clave reside en la naturaleza no lineal de la percepción de la complejidad. Piénsalo así: la diferencia entre estimar una tarea de 1 unidad y una de 2 unidades es relativamente pequeña. Puedes visualizarla con bastante claridad. Pero, ¿qué pasa cuando la tarea se hace grande? La diferencia entre una tarea de 20 unidades y una de 40 unidades es mucho más difícil de calibrar con precisión. Cuanto más grande y compleja es una tarea, más incierta se vuelve nuestra estimación, y menos preciso es nuestro juicio sobre pequeñas variaciones. La escala de Fibonacci refleja esta incertidumbre creciente: los saltos entre números son pequeños al principio, pero se hacen significativamente mayores a medida que avanzamos, forzándonos a reconocer que no podemos ser tan precisos con tareas gigantes. Esto no es un capricho; es una forma inteligente de decirnos: «Ojo, cuanto más grande, más difuso es tu conocimiento».

0: Tarea Trivial o Ya Realizada. Este valor se utiliza para indicar una tarea que es insignificante en términos de esfuerzo o que, por algún motivo, ya está completa o casi completa. Podría ser algo tan simple como un cambio de texto en una interfaz que ya está montada, o la eliminación de una línea de código. Es un «no hay nada que hacer aquí» o «esto ya está hecho, un visto y no visto».
1: Muy Pequeña. Representa una tarea que requiere un esfuerzo mínimo, casi despreciable. Piensa en algo que podrías hacer en unos pocos minutos, o una hora como mucho. Un cambio rápido, un pequeño ajuste, algo que no tiene dependencias ni complicaciones. Es la unidad básica de comparación.
2: Pequeña. Una tarea sencilla y directa, que sabes exactamente cómo abordar. No debería llevar más de unas pocas horas. Es un «sé lo que tengo que hacer y cómo hacerlo».
3: Media. La tarea comienza a tener algo más de sustancia. Podría implicar un día o algo más de trabajo. Es una tarea manejable, pero que requiere cierta concentración y quizás un par de pasos claros.
5: Grande. Aquí la complejidad empieza a aumentar. Podría ser una tarea que lleve varios días. Ya no es tan obvia y podría requerir dividirla mentalmente en sub-pasos, aunque no sea necesario detallarlos. Es el típico «esto me va a llevar un buen rato, pero sé que puedo con ello».
8: Muy Grande. Una tarea considerable. Seguramente involucrará varias partes, y puede que tengas que resolver algún pequeño rompecabezas en el camino. Requiere una planificación más detallada o la interacción con otros componentes del sistema. Es una tarea que sientes que va a ser un verdadero «curro».
13: Enorme. ¡Ojo! Estamos hablando de algo realmente grande y complejo. Aquí la incertidumbre ya es palpable. Puede que no tengas todos los detalles claros, que haya dependencias con otros sistemas o equipos, o que el alcance no esté del todo definido. Es una tarea que, al verla, te hace levantar una ceja y pensar «esto es un señor desafío».
20: Colosal. Este número ya indica un nivel de complejidad tan alto que, probablemente, la tarea debería ser dividida en otras más pequeñas. La incertidumbre es muy elevada, y estimarla con precisión es casi imposible. Es una señal de alarma para decir: «No tenemos suficiente información para esto; necesitamos desglosarlo o investigarlo más a fondo».
40: Demasiado Grande. Si una tarea llega a 40, es una bandera roja gigante. Significa que, tal como está planteada, es casi inabarcable. La ambigüedad es máxima, los riesgos son altísimos. Es un «esto es un proyecto en sí mismo, no una tarea».
100: Impensable. Este valor es casi una declaración: «No hay forma de que podamos abordar esto en su estado actual». La tarea es tan vasta, incierta o mal definida que ni siquiera se puede empezar a pensar en ella. Necesita una redefinición drástica o una investigación profunda antes de cualquier intento de estimación.
∞ (Infinito): Imposible. Este es el «esto no se puede hacer». Por ejemplo, una tarea que requiere una tecnología inexistente, o que choca con una restricción inamovible. Es una forma de decir: «No es viable».
? (Interrogante): No lo sé. Quizás el valor más importante en el contexto de la discusión. Si alguien levanta esta carta, significa que no tiene ni idea de cómo estimar la tarea. Le falta información crucial, no entiende el objetivo, o simplemente no tiene el conocimiento técnico necesario. Es una señal para el equipo de que debe haber una conversación a fondo y quizás una fase de investigación antes de poder estimar.

¿Por Qué y Cuándo Utilizar la Escala de Evans? La Filosofía Detrás de los Números

La utilidad de la escala de Evans va mucho más allá de simplemente asignar un número a una tarea. Es una herramienta poderosa para catalizar la comunicación, desenterrar suposiciones ocultas y construir un entendimiento compartido dentro de un equipo. Aquí te cuento por qué, en mi experiencia, es una joya y cuándo deberías considerar adoptarla.

Ventajas Innegables de su Aplicación

Fomenta la Discusión y el Consenso Real: Imagina que cinco personas estiman una tarea. Si uno dice 3, otro 5, y otro 20, la discrepancia es enorme. En lugar de promediar, la escala de Evans te obliga a debatir. «¿Por qué tú crees que es 20? ¿Qué ves que los demás no vemos? ¿Quizás hay una complejidad o una dependencia que se nos escapa?» Esta conversación es, de lejos, el mayor valor que aporta la escala. No es sobre el número, es sobre el porqué del número.
Reduce el Sesgo Individual y el «Anclaje»: Cuando las personas estiman en voz alta o una detrás de otra, el primero en hablar puede «anclar» las estimaciones de los demás. La escala de Evans, especialmente cuando se usa con técnicas como Planning Poker (donde todos revelan su estimación simultáneamente), elimina este sesgo. Cada uno piensa por sí mismo antes de dejarse influenciar por los demás.
Identifica Tareas Complejas o Incomprendidas: Las grandes divergencias en las estimaciones son una señal de alarma. Significan que no hay un entendimiento común de la tarea. O bien es más compleja de lo que parece, o está mal definida, o alguien tiene información que el resto no. Esto es crucial para detectar problemas antes de que se conviertan en retrasos.
Es Intuitiva una Vez que se Entiende el Concepto Relativo: Al principio puede parecer extraño, pero una vez que el equipo internaliza que los números son relativos (una tarea de 8 es el doble de compleja que una de 4, no que lleve el doble de horas exactas), el sistema se vuelve muy intuitivo. Se basa en una comprensión colectiva de lo que significa cada «punto».
Mejora la Calidad de las Estimaciones con el Tiempo: Cuanto más se usa la escala, más calibrado está el equipo. Aprende de sus errores, ajusta sus percepciones y, con el tiempo, sus estimaciones se vuelven más realistas y predecibles. La retrospectiva juega un papel fundamental aquí, permitiendo comparar estimaciones con el esfuerzo real.
Transforma el Número en una Conversación: Como mencionaba, el número final es menos importante que el diálogo que lo precede. La escala convierte un acto aburrido de asignar números en una sesión dinámica de intercambio de conocimientos y aclaración de dudas.

Contextos Ideales para su Aplicación

Aunque la escala de Evans brilla con luz propia en el desarrollo de software ágil, su utilidad no se limita a este campo. Cualquier escenario donde se necesite cuantificar una percepción subjetiva de esfuerzo, complejidad o incertidumbre puede beneficiarse enormemente.

Desarrollo de Software (Agile, Scrum, Kanban): Es su hábitat natural. En Scrum, se usa para estimar los «puntos de historia» de las tareas (historias de usuario) que se planifican en un sprint. En Kanban, ayuda a entender la complejidad de los ítems en el flujo de trabajo. Es una herramienta indispensable para equipos autoorganizados.
Planificación de Proyectos en General: Más allá del software, cualquier proyecto que implique la estimación de tareas desconocidas o de complejidad variable puede usar esta escala. Ya sea la organización de un evento, el lanzamiento de un producto, o la planificación de una campaña de marketing.
Estimación de Riesgos: Puedes adaptar la escala para estimar el impacto o la probabilidad de ciertos riesgos. Un 3 podría ser un riesgo bajo, un 13 un riesgo considerable que necesita mitigación.
Evaluación de Viabilidad de Ideas: Cuando se evalúan nuevas ideas o funcionalidades, la escala puede ayudar a obtener una primera estimación de su viabilidad y complejidad antes de invertir demasiado tiempo en ellas. Es una especie de filtro inicial para separar el grano de la paja.
Cualquier Escenario con Percepción Subjetiva: Si tu equipo tiene que evaluar algo donde la intuición y la experiencia juegan un papel importante, y quieres que esa intuición se convierta en algo más tangible y discutible, la escala de Evans es tu aliada.

En mi propia experiencia, he visto cómo equipos que antes batallaban con estimaciones que nunca se cumplían, encontraron en la escala de Evans no una solución mágica para la predicción perfecta, sino una forma de hacer sus estimaciones más honestas, más colaborativas y, por ende, más fiables. La verdadera magia no está en el número, sino en la conversación que genera.

Cómo Implementar la Escala de Evans en la Práctica: Una Guía Paso a Paso

Adoptar la escala de Evans en tu equipo no es tan complicado como parece. La técnica más común y efectiva para aplicarla es el Planning Poker, una dinámica lúdica que hace que el proceso de estimación sea mucho más colaborativo y ameno. Ponte en situación, que te cuento cómo se hace.

Preparación Esencial

Definir la Unidad de Estimación: Antes de empezar, el equipo debe acordar qué significan estos números. Lo más común es usar «Puntos de Historia» (Story Points), que son una medida abstracta de esfuerzo, complejidad, riesgo e incertidumbre. No son horas. No son días. Un punto de historia de 3 puede tardar un día para un equipo, y medio día para otro, dependiendo de su velocidad. La clave es la relatividad. Asegúrense de que todos entienden que un 5 es, aproximadamente, el doble de esfuerzo que un 2, y no el doble de horas.
Asegurar que el Equipo Entienda la Escala: Dedica tiempo a explicar la escala de Evans, el significado de cada número (incluyendo el 0, el ?, y el ∞) y, crucialmente, la filosofía detrás de la secuencia no lineal. Un buen ejercicio es pedir al equipo que estime algunas tareas «de referencia» que ya hayan realizado para calibrar su entendimiento. Por ejemplo, «si cambiar el logo en la web es un 2, ¿cuánto es integrar una pasarela de pago?»
Tener Claras las Tareas a Estimar: Asegúrate de que las tareas (historias de usuario, épicas, etc.) que se van a estimar estén bien definidas y descritas, aunque sea a un nivel general. No se puede estimar algo que no se entiende.

El Proceso de Estimación (Usando Planning Poker)

Lectura de la Tarea: El facilitador (o el Product Owner, si hablamos de Scrum) lee la tarea a estimar. Presenta la funcionalidad, el objetivo, el valor que aporta y cualquier criterio de aceptación conocido.
Preguntas y Aclaraciones: Este es un paso crítico. Los miembros del equipo hacen preguntas. «¿Qué pasa si…?», «¿Tenemos acceso a…?», «¿Quién será responsable de…?», «¿Hay dependencias con X?». El objetivo es aclarar cualquier ambigüedad. La conversación debe ser abierta y animada. El facilitador se asegura de que la discusión se centre en entender la tarea, no en la estimación en sí misma aún. Si surgen demasiadas preguntas o el equipo se da cuenta de que la tarea está muy verde, pueden decidir no estimarla y posponerla para una investigación posterior (aquí es donde el «?» se hace muy útil).
Estimación Simultánea: Una vez que se han resuelto las dudas (o al menos se ha llegado a un punto donde no hay más preguntas inmediatas), cada miembro del equipo elige en secreto una carta de su mazo (con los valores de la escala de Evans) que representa su estimación para la tarea. La mantienen boca abajo.
Revelación de las Estimaciones: A la cuenta de tres, todos los miembros del equipo muestran sus cartas al mismo tiempo. ¡Este es el momento de la verdad!
Discusión de las Divergencias: Si todas las cartas son iguales (o muy cercanas), ¡enhorabuena! Hay un consenso claro. Si hay grandes diferencias (por ejemplo, alguien con un 3 y otro con un 13), aquí es donde empieza la magia. Se le pide a las personas con las estimaciones más altas y las más bajas que expliquen su razonamiento. El que estimó bajo puede haber omitido algo, o quizás el que estimó alto conoce una complejidad que el resto desconoce. Esta discusión es vital para alinear la comprensión del equipo.
Reestimación hasta Lograr Consenso: Después de la discusión, el equipo vuelve a estimar la tarea, repitiendo los pasos 3 a 5. Este ciclo continúa hasta que se alcanza un consenso razonable. No se trata de forzar a la gente a cambiar su número, sino de que el equipo llegue a un entendimiento compartido que justifique la estimación final. A veces, si no hay consenso después de varias rondas, la tarea es demasiado grande o incierta y debe dividirse o investigarse más.

Consideraciones Clave al Estimar

La Relatividad de los Valores: Insiste en que los números son relativos. Un «8» hoy no es un «8» absoluto en todos los equipos o en todos los contextos. Es un «8» relativo a la comprensión actual de tu equipo sobre la complejidad de sus tareas.
La Importancia del Diálogo: Recuerda a tu equipo que el valor del Planning Poker no está en el número final, sino en el diálogo y la comprensión compartida que surge de las discusiones.
No Forzar el Consenso si la Incertidumbre es Real: Si después de varias rondas de discusión el equipo sigue teniendo estimaciones muy dispares y la incertidumbre es real, es una señal de que la tarea es demasiado grande o ambigua. En lugar de forzar un número, la mejor opción puede ser dividir la tarea en otras más pequeñas o realizar una «investigación» o «descubrimiento» (un spike en Scrum) para aclarar los detalles.
Actualizar las Estimaciones: Las estimaciones no son de piedra. A medida que el equipo aprende más sobre una tarea (durante su desarrollo, por ejemplo), la estimación inicial puede revisarse. La flexibilidad es clave en la agilidad.

He visto cómo esta dinámica transforma la forma en que los equipos abordan las estimaciones. De sesiones tediosas y llenas de especulaciones, se convierten en debates animados y productivos que no solo generan mejores estimaciones, sino que también fortalecen la cohesión del equipo y su capacidad para enfrentar lo desconocido.

Desgranando Cada Valor de la Escala de Evans: Más Allá de los Números

Ya hemos repasado qué es la escala de Evans y cómo aplicarla. Pero para sacarle el jugo de verdad, hay que ir más allá de la simple memorización de los números. Cada valor en la secuencia Fibonacci (o similar) de la escala de Evans lleva consigo un mensaje implícito sobre la naturaleza de la tarea. Entender este mensaje es crucial para que las estimaciones sean realmente útiles.

0: Tarea Trivial, Hecha, o No Necesaria

Este es el comodín para lo que apenas requiere esfuerzo. Imagina que el cliente pide cambiar el color de un botón a «azul oscuro», y justo la semana anterior ya lo habíais puesto de ese color. ¡Es un 0! O quizás se pide una funcionalidad que ya está implementada y activa. También se usa si la tarea es tan trivial que ni siquiera merece la pena discutirla, como «cambiar la coma por un punto» en un texto que ya está visible. Es un «cero patatero», pero útil para limpiar la pila de trabajo.

1: Muy Pequeña, el Visto y No Visto

Aquí hablamos de tareas que son casi instantáneas. Un cambio de texto simple, ajustar una propiedad CSS, corregir un error tipográfico en una base de datos. Es un trabajo que sabes hacer con los ojos cerrados, sin dependencias y con una complejidad mínima. Si puedes resolverlo en menos de una hora, es un candidato a 1. Es el equivalente a «esto lo hago en lo que me tomo el café».

2: Pequeña, Directa y sin Sorpresas

Una tarea sencilla. Sabes lo que tienes que hacer, cómo hacerlo y no esperas sorpresas. Quizás una pequeña función nueva, un campo adicional en un formulario, o una modificación en una pantalla existente que no implica grandes cambios en la lógica. Podría llevar un par de horas o media jornada. Es un «esto está chupado, lo tengo claro».

3: Moderada, Un Día de Trabajo Concreto

La tarea empieza a tener su miga, pero es perfectamente abordable por una sola persona en un día o algo más. Podría ser implementar una característica estándar, conectar dos componentes ya existentes, o refactorizar una pequeña parte de código. Requiere concentración, pero el camino es bastante claro. Aquí ya empiezas a notar que el «curro» es real.

5: Media, con sus Detallitos

Esta es una tarea de tamaño medio. Puede llevar varios días. Implica un poco más de planificación o la coordinación con otras partes. Puede que haya un par de decisiones de diseño que tomar, o que tengas que investigar alguna librería. La mayoría de las historias de usuario de tamaño «normal» caen en esta categoría. Es un «esto va a ser un buen tramo, pero lo veo».

8: Grande, el Rompecabezas que Requiere Pensar

Entramos en el terreno de las tareas grandes. Una tarea de 8 puntos de historia ya es un verdadero desafío. Puede requerir días de trabajo intensivo, o incluso una semana. A menudo implica integrar un nuevo servicio, desarrollar una funcionalidad compleja con múltiples flujos de usuario, o abordar un problema técnico espinoso. Hay incertidumbre, pero se considera manejable. Es una «patata caliente» que sabes que vas a tener que cocinar con paciencia y esmero.

13: Muy Grande, la Barrera de la Incertidumbre

Aquí la cosa se pone seria. Una tarea de 13 significa que es considerablemente compleja y, sobre todo, que la incertidumbre es elevada. Quizás no se tienen todos los requisitos claros, hay dependencias externas importantes, o se necesita una investigación previa para entender cómo abordarla. Es una fuerte señal de que la tarea podría ser demasiado grande para un solo sprint (en Scrum) o que necesita ser descompuesta antes de poder ser estimada con mayor precisión. Si tu equipo da muchos 13s, es un síntoma de que las historias de usuario son demasiado amplias o están mal definidas. Es un «esto me da miedo, no sé ni por dónde empezar sin más información».

20: Colosal, ¿Podemos Dividirla?

Este valor es una alarma ruidosa. Si un equipo estima una tarea en 20, es casi una declaración de que no está bien entendida o que es un proyecto en sí misma. La incertidumbre es masiva, los riesgos son altos. Prácticamente siempre, una tarea de 20 debería ser dividida en tareas más pequeñas y manejables, o requiere una fase de «descubrimiento» significativa. Es un «esto no es una tarea, es una epopeya; necesitamos un mapa detallado».

40: Demasiado Grande, Imposible de Acotar Ahora

Ver un 40 es ver una montaña intransitable sin el equipo de alpinismo adecuado. Es una señal de que la tarea, tal como está planteada, es abrumadora y no debería ser ni considerada para un sprint. Es un indicativo de que hay una falta fundamental de comprensión o que el alcance es gigantesco. La tarea necesita ser reformulada, redefinida y, casi con total seguridad, desglosada en múltiples tareas mucho más pequeñas. Es un «esto es un monstruo, ¿qué estamos haciendo?»

100: Impensable, No Tenemos Ni la Más Remota Idea

Este valor es una expresión de total confusión e incapacidad para estimar. No se sabe por dónde empezar, el problema es demasiado vago, o el equipo carece por completo del conocimiento necesario. Una tarea con un 100 no debe ser abordada; debe ser investigada en profundidad, o incluso descartada si no se puede aclarar. Es el grito de «¡no tenemos ni idea de cómo hacer esto, ni siquiera sabemos qué es ‘esto’ exactamente!».

∞ (Infinito): Imposible de Realizar

Este valor es el «no se puede hacer». Por ejemplo, el cliente pide una función que choca con las leyes de la física, o que requiere un presupuesto o un tiempo tan desorbitado que es inviable. No es que sea compleja; es que es, literalmente, imposible en las condiciones actuales. Es el «estamos pidiendo peras al olmo».

? (Interrogante): Necesito Más Información

El signo de interrogación es una de las cartas más honestas y valiosas. Si un miembro del equipo la muestra, significa que no puede estimar porque le falta información crítica. No entiende la tarea, no tiene suficiente contexto, o no posee el conocimiento técnico necesario. Esta carta es una llamada de atención para que el equipo profundice en la discusión y proporcione la información que falta. Es un «no sé nada de esto, necesito que me expliquen con peras y manzanas».

Comprender estos matices hace que la escala de Evans sea mucho más que una simple herramienta de estimación; se convierte en un lenguaje compartido que ayuda a los equipos a comunicar la complejidad y la incertidumbre de forma efectiva. Es un lenguaje que te permite saber, de un vistazo, si tu equipo está remando en la misma dirección o si hay un «elefante en la habitación» que necesita ser abordado.

Errores Comunes al Aplicar la Escala de Evans y Cómo Evitarlos

Aunque la escala de Evans es una herramienta fantástica, como cualquier otra, puede malinterpretarse o aplicarse incorrectamente. He visto en primera persona cómo algunos equipos, con la mejor de las intenciones, caían en trampas que minaban la efectividad de sus estimaciones. Aquí te dejo los errores más comunes y, lo más importante, cómo evitarlos.

1. Tratar los Puntos de Historia como Horas Absolutas

El error: Este es, con diferencia, el más frecuente. Los equipos, y a veces los Product Owners o Stakeholders, caen en la tentación de decir «un 8 son dos días de trabajo» o «un 3 son cuatro horas». Esto anula por completo el propósito de los puntos de historia, que están diseñados para ser una medida relativa de la complejidad, la incertidumbre, el riesgo y el esfuerzo, no una medida de tiempo. Cuando los puntos se convierten en horas, se pierde el beneficio de la estimación ágil: la capacidad de trabajar con la incertidumbre y la naturaleza no lineal de la complejidad.

Cómo evitarlo: Desde el primer momento, educa a todo el mundo (equipo y stakeholders) sobre la naturaleza relativa y abstracta de los puntos de historia. Insiste en que son una medida de tamaño y complejidad, no de tiempo. Utiliza «tareas de referencia» para calibrar: «Si una tarea que ya hicimos y consideramos que era pequeña y sencilla es un 3, ¿cómo de grande es esta otra en comparación?». Con el tiempo, el equipo desarrollará un sentido de la «velocidad» (velocity) – cuántos puntos de historia pueden completar en un sprint – lo cual sí te da una indicación de lo que pueden lograr en un periodo, sin forzar una equivalencia directa a horas.

2. Forzar el Consenso a Toda Costa

El error: En el afán de llegar a un número rápido, algunos equipos presionan para que todos «se pongan de acuerdo», incluso si no hay un entendimiento común real. Si alguien da un 3 y otro un 13, y en lugar de discutir los porqués se les dice «vamos a dejarlo en 8 y a otra cosa mariposa», se pierde toda la riqueza de la discusión y las suposiciones ocultas no salen a la luz.

Cómo evitarlo: Recuerda que el objetivo del Planning Poker no es obtener un número, sino alcanzar un entendimiento compartido. Si hay una gran divergencia, es una señal de que la tarea necesita más discusión o que está mal definida. Anima a los extremos (el que dio el número más alto y el más bajo) a explicar su razonamiento. Si después de varias rondas el consenso no se logra, es probable que la historia de usuario sea demasiado grande o incierta y deba ser dividida o requerir un «spike» (investigación) antes de una estimación real.

3. No Discutir las Divergencias Significativas

El error: Directamente relacionado con el anterior. Algunos equipos revelan las cartas, ven las diferencias y, en lugar de dialogar, simplemente promedian o eligen el número de la mayoría. Sin la discusión, la escala de Evans pierde su principal superpoder: desenmascarar la falta de conocimiento o la complejidad oculta.

Cómo evitarlo: Asegúrate de que las discusiones sean el centro de la sesión de estimación. Pregunta a quienes dieron valores muy diferentes qué les llevó a esa estimación. Anima al «dueño» de la estimación más alta a explicar los obstáculos o riesgos que ve, y al de la más baja a compartir por qué cree que es más sencilla. A menudo, las mejores soluciones o los mayores aprendizajes surgen de estas conversaciones.

4. Estimar Individualmente sin Equipo

El error: A veces, por ahorrar tiempo, se pide a cada desarrollador que estime las tareas por su cuenta y luego se recogen los números. Esto elimina el componente colaborativo y la riqueza de perspectivas. La estimación se convierte de nuevo en un ejercicio solitario, propenso a sesgos individuales y a la omisión de dependencias o complejidades que solo surgen al debatir en grupo.

Cómo evitarlo: Las estimaciones deben ser un esfuerzo de equipo. Si es imposible reunirse físicamente, usa herramientas online de Planning Poker. Lo importante es que todos vean las estimaciones de los demás y que haya un foro para la discusión en tiempo real. La inteligencia colectiva es mucho más precisa que la suma de inteligencias individuales aisladas.

5. Ignorar el Significado del «?» y el «∞»

El error: Algunas veces, estos valores especiales se ven como un «no sé» perezoso o un «imposible» sin fundamento. Si alguien levanta una de estas cartas y el equipo no indaga por qué, se pierde la oportunidad de identificar bloqueos críticos o de darse cuenta de que una tarea no es viable en absoluto.

Cómo evitarlo: Trata estos valores con la seriedad que merecen. Si alguien muestra un «?», pregunta: «¿Qué información necesitas? ¿Podemos conseguirla ahora o la tarea necesita un spike?». Si es un «∞», pregunta: «¿Por qué es imposible? ¿Hay alguna restricción técnica o de negocio que lo impida?». Estos valores son vitales para identificar si una tarea necesita más investigación o directamente no debería ser abordada.

Evitar estos errores comunes no solo mejora la precisión de las estimaciones, sino que también fortalece la cohesión del equipo, mejora la comunicación y, en última instancia, conduce a una planificación de proyectos más realista y exitosa. Es un proceso de mejora continua, y cada error es una oportunidad de aprendizaje.

Experiencia Personal y Reflexiones sobre la Escala de Evans

He tenido el privilegio de trabajar con equipos que adoptaron la escala de Evans, y la verdad es que la transformación es palpable. Recuerdo un equipo en particular, al que llamaré «Los Navegantes», que solía luchar con una planificación que nunca cuadraba. Sus estimaciones eran un auténtico rompecabezas: un desarrollador se comprometía con una fecha, otro se reía, y al final, el Product Owner se quedaba con la sensación de que navegaban a ciegas.

Cuando introdujimos el Planning Poker y la escala de Evans, al principio hubo escepticismo. «¿Cartas? ¿Fibonacci? ¿No podemos simplemente decir cuántos días tardaremos?». Pero insistimos en el «porqué». Explicamos que la idea no era predecir el futuro con exactitud milimétrica, sino entender la complejidad relativa y, sobre todo, dialogar. La primera sesión fue un poco caótica, con estimaciones por todo el mapa. Pero al forzar la discusión, comenzaron a emerger cosas fascinantes.

Recuerdo una historia de usuario que, a primera vista, parecía un 5 (media). Pero cuando el desarrollador más veterano levantó un 13 y el más joven un 3, la conversación se encendió. El joven no había tenido en cuenta las complejísimas dependencias con un sistema legado externo, ni la necesidad de hacer pruebas de rendimiento específicas que el veterano sí conocía. Esa discusión nos ahorró semanas de retraso y frustración, porque decidimos dividir la tarea, investigar la dependencia y abordar primero el riesgo. Esa fue una de esas revelaciones que te hacen decir: «¡Eureka! Esto es un tesoro.»

Mi perspectiva es que la escala de Evans es una herramienta de comunicación disfrazada de herramienta de estimación. Su verdadero valor no reside en la magia de la secuencia de Fibonacci, sino en cómo obliga a los equipos a hablar, a desafiar sus suposiciones, a compartir conocimientos y, en última instancia, a construir una comprensión colectiva de lo que están tratando de lograr. Es un proceso que empodera al equipo, porque las estimaciones ya no son impuestas por un jefe o generadas por una única persona; son el resultado de un consenso informado y colaborativo.

He visto cómo esta herramienta ayudó a los equipos a volverse más transparentes, a identificar problemas antes de que se gestaran y a desarrollar un sentido de responsabilidad compartida por las estimaciones. Ya no era «la estimación de Juan», sino «la estimación del equipo». Y esa es una diferencia abismal. Si estás buscando una forma de mejorar la predictibilidad de tus proyectos y, aún más importante, la salud de tu comunicación en equipo, te diría sin dudarlo: dale una oportunidad a la escala de Evans. Quizás te sorprendas de lo mucho que te puede ayudar a navegar por la incertidumbre de la planificación de proyectos.

Preguntas Frecuentes (FAQs) sobre la Escala de Evans

¿Quién creó la escala de Evans y por qué se llama así?

La escala de Evans, tal como la conocemos y aplicamos en el Planning Poker, no fue «creada» por una única persona con ese nombre. La asociación más directa con su popularización en el ámbito ágil se le atribuye a James Grenning, quien introdujo la idea de usar una escala de Fibonacci para la estimación durante las reuniones de Planning Poker. El nombre «Evans» se asocia comúnmente con la escala debido a Tom Evans, un influyente consultor y evangelista de Scrum, quien abogó por el uso de esta secuencia numérica para la estimación de puntos de historia en el Planning Poker.

La idea de utilizar una secuencia no lineal para la estimación no es nueva; la secuencia de Fibonacci, en particular, ha sido reconocida por su utilidad para expresar el aumento de la incertidumbre a medida que el tamaño de algo crece. Así, aunque no hay un «Sr. Evans» que sea el inventor de la secuencia, su nombre se ha arraigado en la comunidad ágil como sinónimo de esta particular aplicación de Fibonacci para las estimaciones de complejidad.

¿Es lo mismo la escala de Evans que los Puntos de Historia?

No, no son lo mismo, aunque están intrínsecamente relacionados y a menudo se usan juntos. La escala de Evans es la secuencia numérica (0, 1, 2, 3, 5, 8, etc.) que se utiliza como un conjunto de opciones para estimar. Los Puntos de Historia (Story Points) son la unidad de medida abstracta que se asigna a una tarea (historia de usuario) utilizando esa escala. Piénsalo así: la escala de Evans es el conjunto de pesos que tienes disponibles (1kg, 2kg, 5kg…), y los Puntos de Historia son el peso que le asignas a un objeto («esta manzana pesa 3kg»).

Los Puntos de Historia buscan cuantificar la complejidad, el riesgo, la incertidumbre y el esfuerzo relativo de una tarea, no el tiempo. La escala de Evans proporciona una manera estandarizada y no lineal para expresar ese «tamaño» en Puntos de Historia, facilitando la discusión y el consenso en el equipo. Son dos caras de la misma moneda de estimación ágil, pero con roles distintos.

¿Se puede modificar la escala de Evans? ¿Es obligatorio usar Fibonacci?

Sí, la escala se puede modificar, pero con cierta cautela y un buen motivo. Aunque la secuencia de Fibonacci es la más popular y probada por su capacidad para reflejar la incertidumbre creciente, no es una ley inquebrantable. Algunos equipos prefieren una escala ligeramente diferente, como por ejemplo 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, para incluir tareas muy, muy pequeñas, o quizás se omite el 100 o el 40 si rara vez se encuentran con tareas tan grandes.

Lo importante al modificarla es mantener la naturaleza no lineal y exponencial de la escala. Esto es crucial porque es lo que fuerza al equipo a reconocer que, cuanto más grande es la tarea, menos precisos pueden ser en su estimación y más incertidumbre hay. Si cambias la escala a una lineal (1, 2, 3, 4, 5…), pierdes esta ventaja fundamental y podrías caer de nuevo en la trampa de tratar los números como unidades de tiempo exactas. Cualquier modificación debe ser discutida y acordada por todo el equipo, y debe servir para un propósito claro que mejore la estimación y la comunicación.

¿Es útil la escala de Evans fuera del desarrollo de software?

¡Absolutamente! Aunque ha ganado popularidad en el mundo del desarrollo de software ágil, la lógica subyacente de la escala de Evans es aplicable en cualquier campo que requiera la estimación de esfuerzo subjetivo, complejidad o incertidumbre. Piensa en la planificación de eventos, campañas de marketing, investigación y desarrollo, proyectos de consultoría, o incluso la evaluación de riesgos en cualquier industria. Si tienes un equipo que necesita estimar tareas con distintos niveles de complejidad y conocimiento, y quieres fomentar la discusión y un entendimiento común, la escala de Evans puede ser una herramienta invaluable.

Por ejemplo, un equipo de marketing podría usarla para estimar la complejidad de lanzar una nueva campaña (desde un 1 para un post sencillo en redes sociales hasta un 20 para una campaña multimedia global). La clave es adaptar la «unidad de estimación» al contexto de tu trabajo (por ejemplo, «puntos de complejidad de marketing» en lugar de «puntos de historia») y educar al equipo en su uso relativo.

¿Qué hago si todo el equipo da «pregunta» (?) en la estimación de una tarea?

Si la mayoría o todo el equipo muestra la carta de «interrogante» (?), es una señal clarísima de que la tarea no está lo suficientemente clara para ser estimada. No es un fracaso; al contrario, es un éxito del proceso, porque ha revelado una falta crítica de información o un entendimiento deficiente antes de que el trabajo comience. En este escenario, tienes varias opciones, que a menudo se combinan:

Profundizar en la Discusión: Permite que el equipo exprese exactamente qué les impide estimar. ¿Faltan requisitos? ¿No se entiende el objetivo de negocio? ¿Hay una dependencia técnica desconocida?

Realizar un «Spike» (Investigación): Si la falta de información es sustancial, la tarea no debe estimarse en ese momento. En su lugar, se crea una nueva tarea muy pequeña (un «spike») con un objetivo de investigación (ej: «Investigar API de pago X para determinar viabilidad»). Esa tarea de investigación sí se puede estimar con un número bajo (quizás un 3 o 5), y una vez que se complete, el equipo tendrá la información para estimar la tarea original.

Dividir la Tarea: A veces, el «?» significa que la tarea es tan grande o abstracta que no se puede digerir. La solución es volver al Product Owner (o quien defina las tareas) para desglosarla en partes más pequeñas y manejables, cada una de las cuales pueda ser estimada de forma más independiente.

En resumen, un «pregunta» es una invitación a la aclaración, no una señal para forzar una estimación ciega. Te ahorra dolores de cabeza a futuro.

¿Cómo se manejan las tareas con «infinito» (∞) en la escala de Evans?

Una tarea con un valor de «infinito» (∞) es una declaración contundente de «imposibilidad» o «inviabilidad» en las condiciones actuales. No significa que sea extremadamente compleja; significa que el equipo percibe que no se puede hacer, punto. Esto puede deberse a:

Restricciones Técnicas Insuperables: La tecnología actual no lo permite, o requeriría un desarrollo desde cero de una nueva tecnología que no está dentro del alcance del proyecto.

Barreras de Negocio o Legales: Choca con una ley, una política de la empresa inamovible, o un requisito que no tiene sentido estratégico en absoluto.

Recursos Absolutamente Insuficientes: No se cuenta con el personal, el presupuesto o el tiempo para abordar algo de tal magnitud.

Cuando un equipo asigna «infinito», el diálogo es crucial. Se debe preguntar: «¿Por qué crees que es imposible? ¿Qué lo hace inviable?» Esta discusión puede llevar a redefinir la tarea drásticamente, a eliminarla del backlog si es verdaderamente inviable, o a entender que requiere una decisión a nivel estratégico superior. Es una señal para el liderazgo de que hay un «stopper» fundamental que va más allá de la complejidad habitual de una tarea.

Estas preguntas frecuentes demuestran que la escala de Evans es mucho más que una secuencia de números; es una herramienta que provoca conversaciones, fomenta la transparencia y ayuda a los equipos a navegar por la incertidumbre con mayor confianza y, sobre todo, de manera colaborativa.

Spread the love