Semáforo para no estimar historias a medio entender

En una ronda de planning poker, el problema no siempre es que el equipo no se ponga de acuerdo. A veces el problema es más básico: no está estimando la misma historia.

La escena es familiar. Una persona vota 2 porque imagina un cambio pequeño de interfaz. Otra vota 13 porque incluye permisos, migración de datos y pruebas de regresión. Alguien usa “?” porque no entiende qué pasa con un caso límite. Si el equipo intenta resolverlo buscando un promedio, la conversación se vuelve extraña: parece una negociación sobre puntos, pero en realidad es una conversación pendiente sobre alcance.

La estimación relativa y el planning poker ayudan a comparar esfuerzo, complejidad e incertidumbre, como explica Atlassian en su guía sobre story points y estimación ágil. Pero esa práctica solo funciona bien cuando el equipo comparte una lectura mínima del trabajo. Si la dispersión es alta, la ronda no ha fallado: ha enseñado que la historia todavía necesita refinamiento.

Este artículo propone un marco sencillo para decidir qué hacer cuando aparecen votos muy separados o respuestas con “?”. No busca que el equipo discuta menos, sino que discuta mejor: sobre riesgos, dependencias y supuestos, no sobre quién tiene “la cifra correcta”.

La dispersión no es un número: es una diferencia de lectura

Una estimación dispersa suele tener al menos una de estas causas:

• Alcance ambiguo: cada persona incluye funcionalidades distintas.
• Criterios de aceptación incompletos: no está claro qué significa “terminado”.
• Dependencias no visibles: alguien sabe que hace falta otro equipo, sistema o permiso.
• Riesgo técnico desigual: una parte del equipo ve incertidumbre donde otra ve rutina.
• Falta de contexto de producto: se desconoce el objetivo o la prioridad real.

La clave es no tratar todas esas causas como desacuerdo. Algunas sí son discrepancias sanas: por ejemplo, una persona cree que la integración es sencilla y otra recuerda una limitación técnica. Esa diferencia merece conversación y puede mejorar la estimación.

Pero otras señales indican que la historia aún no está madura. Si varias personas dicen “depende”, votan “?” o describen versiones incompatibles del trabajo, el objetivo ya no debería ser cerrar puntos. El objetivo pasa a ser descubrir qué información falta para poder estimar con responsabilidad.

Aquí conviene recordar un valor central del Agile Manifesto: individuos e interacciones por encima de procesos y herramientas. El planning poker no es el proceso que decide por el equipo; es una excusa estructurada para provocar la conversación correcta.

El semáforo de madurez: seguir, aclarar, dividir o aplazar

Cuando reveles votos, evita reaccionar solo al número más alto o al más bajo. Mira la forma de la distribución y decide con este semáforo.

Señal en la ronda	Lectura probable	Decisión recomendada
Votos cercanos y sin “?”	Entendimiento suficiente	Cerrar estimación o hacer una aclaración breve
Dos grupos de votos claros	Hay dos interpretaciones o niveles de riesgo	Preguntar qué incluye cada grupo y ajustar la historia
Votos muy separados, sin patrón	Falta contexto compartido	Pausar la estimación y aclarar supuestos
Varios “?”	Información insuficiente	No forzar número; definir qué dato falta
Un voto extremo bien argumentado	Riesgo oculto o dependencia relevante	Investigar el riesgo antes de cerrar

Este semáforo no pretende ser matemático. Es una ayuda de facilitación. El Scrum Master o el Product Owner pueden usarlo para cambiar la pregunta: de “¿qué número ponemos?” a “¿qué estamos entendiendo distinto?”.

En herramientas de planning poker como Stimo, la ayuda de Stimo documenta votación privada, revelado de resultados, uso de “?” como señal de falta de información y lectura de media, mediana y resultados por perfil. Esos datos no sustituyen el criterio del equipo, pero pueden ayudar a ver si la ronda está concentrada o si hay una distancia que merece conversación.

Tres preguntas antes de repetir la votación

Repetir una ronda puede ser útil, pero solo si entre una ronda y otra cambió algo: una aclaración, una división, una decisión de alcance o una dependencia resuelta. Si no cambió nada, la segunda votación suele repetir el mismo bloqueo con algo más de cansancio.

Antes de votar otra vez, prueba esta secuencia:

1. Pregunta al voto bajo: “¿Qué asumiste que ya estaba resuelto o fuera de alcance?”
2. Pregunta al voto alto: “¿Qué riesgo, dependencia o trabajo adicional estás incluyendo?”
3. Pregunta a quien votó “?”: “¿Qué dato concreto necesitarías para poder votar?”

Estas preguntas reducen la conversación a supuestos observables. No buscan defender posiciones, sino separar tres capas que a menudo se mezclan: alcance, incertidumbre y esfuerzo.

Después de escuchar, el equipo debería elegir una de cuatro acciones:

• Aclarar y revotar: si el malentendido era pequeño y ya quedó resuelto.
• Dividir la historia: si hay partes con valor o riesgo separable.
• Convertir una duda en tarea de investigación: si falta información técnica o de producto.
• Aplazar la estimación: si la historia aún no tiene criterios suficientes.

La decisión más madura puede ser no estimar todavía. Eso no retrasa el trabajo; evita fabricar una falsa precisión.

Ejemplo aplicado: una historia que parecía pequeña

Ejemplo hipotético. El equipo está refinando esta historia:

“Como usuario, quiero exportar el listado de pedidos a CSV para analizarlo fuera de la plataforma.”

Primera ronda: Developer A vota 3, QA vota 5, UX vota 2, Developer B vota 13 y otra persona vota “?”.

Si el equipo promedia, podría cerrar un número intermedio y seguir. Pero la dispersión está diciendo algo más interesante.

El facilitador pregunta primero al voto bajo:

• UX explica que solo imaginaba añadir un botón visible en una pantalla existente.
• Developer A asumía que ya existía un endpoint interno y que solo había que exponerlo.

Después pregunta al voto alto:

• Developer B aclara que no existe endpoint, que el CSV debe respetar filtros avanzados y que algunos campos tienen reglas de permisos.

Finalmente pregunta por el “?”:

• La persona no sabe si el CSV debe incluir todos los pedidos históricos o solo la página filtrada.

Con esa conversación, el equipo descubre que no estaba estimando una historia, sino tres decisiones mezcladas: experiencia de exportación, reglas de datos y alcance del histórico.

Decisión razonable:

1. Aclarar con Product Owner si el primer incremento solo exporta el resultado filtrado visible.
2. Separar una historia técnica o spike si hay incertidumbre sobre permisos y rendimiento.
3. Reescribir criterios de aceptación antes de votar otra vez.

La ronda no produjo un número final, pero sí produjo una mejor decisión: no meter una historia ambigua en el Sprint como si fuera pequeña.

Errores comunes al leer la dispersión

Error 1: tratar el voto alto como pesimismo. A veces lo es, pero muchas veces contiene información que el resto no tiene. Pide el supuesto antes de discutir la cifra.

Error 2: empujar al “?” para que elija un número. Si alguien declara falta de información, esa señal vale más que una estimación inventada. Pregunta qué dato necesita.

Error 3: confundir consenso con entendimiento. Un equipo puede votar parecido por costumbre, presión o anclas previas. La dispersión revela diferencias visibles, pero la alineación aparente también merece una pregunta ocasional: “¿qué estamos incluyendo?”.

Error 4: dividir siempre que haya votos separados. Dividir ayuda cuando hay partes con valor, riesgo o aprendizaje separable. Si el problema es una duda puntual de negocio, quizá basta con aclarar un criterio.

Error 5: usar la herramienta como árbitro. Media, mediana y dispersión son señales. La decisión sigue siendo del equipo. Si necesitas revisar cómo preparar una sesión, la FAQ de Stimo reúne dudas habituales sobre roles, salas y votaciones, pero el criterio de facilitación sigue importando más que la pantalla.

Una plantilla de facilitación para la próxima ronda

Puedes copiar esta secuencia en tu próximo refinamiento:

1. Antes de votar: “Estamos estimando alcance, riesgos y dependencias de esta versión de la historia.”
2. Al revelar: “No vamos a defender números; vamos a explicar supuestos.”
3. Si hay dispersión: “Voto bajo: ¿qué dejaste fuera? Voto alto: ¿qué estás incluyendo? ‘?’: ¿qué dato falta?”
4. Tras escuchar: “¿La historia necesita aclaración, división, investigación o podemos revotar?”
5. Antes de cerrar: “¿Qué cambió en nuestro entendimiento desde la ronda anterior?”

La pregunta final es la más importante. Si nada cambió, votar de nuevo es teatro. Si cambió el alcance, el riesgo o la información disponible, entonces una nueva ronda sí puede aportar una estimación más responsable.

Conclusión práctica

La dispersión en planning poker no es una molestia que haya que tapar rápido. Es una señal temprana de que el equipo aún no comparte la misma historia. Bien usada, evita estimaciones frágiles, conversaciones tardías y compromisos basados en supuestos invisibles.

La próxima vez que aparezcan un 2, un 13 y un “?”, no preguntes “¿cómo llegamos al consenso?”. Pregunta primero: “¿qué historia está estimando cada persona?”. La respuesta te dirá si conviene aclarar, dividir, investigar o aplazar. Y esa decisión vale más que un número cerrado por prisa.

Fuentes consultadas

• Atlassian · Story points y estimación
• Agile Manifesto
• Stimo · Ayuda
• Stimo · Preguntas frecuentes