La ronda terminó dispersa: protocolo para decidir el siguiente paso

Una ronda de planning poker con votos muy separados suele activar una reacción incómoda: alguien intenta defender su número, otra persona propone hacer la media y el equipo empieza a negociar puntos como si estuviera cerrando un precio. El problema no es que haya desacuerdo. El problema es tratarlo como una molestia que hay que eliminar rápido.

En estimación ágil, los story points funcionan mejor cuando ayudan al equipo a comparar esfuerzo, complejidad e incertidumbre de forma relativa, no cuando se convierten en una cifra exacta. Atlassian explica el planning poker como una práctica para estimar en grupo y calibrar historias comparándolas con referencias conocidas. Esa lógica se rompe si, después de revelar votos muy distintos, el equipo salta directamente a “dejémoslo en 5”.

La dispersión no decide por ti, pero sí te hace una pregunta útil: ¿estamos hablando de la misma historia? Si la respuesta es no, la siguiente acción no debería ser cerrar una cifra, sino mejorar el entendimiento compartido. Ahí conviene tener un protocolo simple: mirar la dispersión, escuchar los extremos y elegir entre aclarar, dividir o repetir la ronda.

Qué te está diciendo realmente la dispersión

La dispersión es la distancia entre las estimaciones del equipo. En una sesión de planning poker, puede aparecer porque las personas están valorando aspectos distintos: una piensa en desarrollo backend, otra en pruebas, otra en permisos, otra en UX, otra en dependencias externas.

No toda dispersión significa lo mismo. Puede indicar al menos cuatro cosas:

• Falta de alcance: no está claro qué entra y qué queda fuera.
• Riesgo oculto: alguien conoce una dependencia, deuda técnica o integración que el resto no está considerando.
• Tamaño excesivo: la historia contiene varios trabajos que podrían estimarse mejor por separado.
• Diferente referencia de puntos: el equipo no está comparando con las mismas historias base.

La recomendación práctica es no discutir primero el número. Discute primero el modelo mental detrás de los votos. Dos preguntas suelen desbloquear más que diez minutos de debate abstracto:

1. “Quienes votasteis bajo, ¿qué asumisteis que no estaba incluido?”
2. “Quienes votasteis alto, ¿qué riesgo o trabajo estáis incorporando?”

Esto conecta con una idea central del Agile Manifesto: valorar más las interacciones y la colaboración que el seguimiento mecánico de un proceso. El planning poker no es la finalidad; es un mecanismo para provocar la conversación correcta.

Protocolo ADR: aclarar, dividir o repetir

Para no convertir cada desacuerdo en una reunión larga, usa un protocolo de tres salidas. ADR no pretende “resolver” todas las estimaciones; sirve para decidir qué necesita la historia antes de avanzar.

Señal tras revelar votos	Pregunta de diagnóstico	Acción recomendada	Cuándo volver a votar
Votos separados por supuestos distintos	¿Qué entendió cada persona sobre alcance, criterios o dependencias?	Aclarar la historia	Cuando el alcance haya cambiado o se haya hecho explícito
Votos altos porque aparecen varios trabajos	¿Podemos separar una entrega útil más pequeña?	Dividir la historia	Después de definir los cortes y criterios de cada parte
Votos dispersos pero la conversación converge rápido	¿Ha cambiado realmente el entendimiento del equipo?	Repetir la ronda	Solo si los supuestos nuevos son compartidos
Votos con “?” o dudas no resolubles en la sala	¿Qué información falta y quién puede traerla?	Aplazar o pedir aclaración externa	Cuando exista información nueva

La clave está en evitar una segunda ronda automática. Repetir sin haber cambiado nada solo produce otra foto del mismo desacuerdo. La segunda ronda tiene sentido cuando el equipo ha aprendido algo: se corrigió un criterio de aceptación, se eliminó una dependencia, se separó una parte del alcance o se hizo visible un riesgo.

Si usas Stimo, esta lectura encaja con el flujo documentado en su guía de ayuda: los perfiles votantes estiman en privado, el organizador revela los votos y el equipo revisa resultados como mediana, media y dispersión. La herramienta no sustituye la conversación, pero ayuda a separar dos momentos: primero votar sin arrastre de grupo; después interpretar juntos lo que aparece.

Ejemplo aplicado: exportación de informes

Ejemplo hipotético. Un equipo refina esta historia:

“Como responsable de operaciones, quiero exportar el informe mensual en CSV para analizarlo en una herramienta externa”.

Los criterios visibles son:

• El CSV incluye fecha, cliente, estado y total.
• La exportación se lanza desde la pantalla de informes.
• Solo usuarios con permiso de administración pueden exportar.

Primera ronda de planning poker: 2, 3, 3, 8, 13.

Si el equipo cerrara una media, perdería la señal. En lugar de eso, el facilitador pregunta por los extremos.

Quienes votaron 2 o 3 asumieron que el informe ya existe, que solo hay que añadir un botón y serializar los datos actuales. Quien votó 8 recuerda que los permisos de administración no están implementados en esa pantalla. Quien votó 13 añade que el informe mensual actual se calcula en frontend y no hay endpoint reutilizable para exportarlo de forma fiable.

Ahora el equipo no tiene un problema de puntos; tiene tres interpretaciones de producto y arquitectura.

Decisión con ADR:

• Aclarar: el Product Owner confirma que la primera versión puede limitarse a los campos ya disponibles en backend.
• Dividir: el equipo separa “crear endpoint de exportación CSV con campos existentes” de “homogeneizar permisos de administración en informes”.
• Repetir: solo se vuelve a votar la primera historia, ya recortada y con criterios actualizados.

Resultado de la segunda ronda para la historia recortada: 3, 3, 5, 5, 5. Aún hay diferencia, pero ya no hay desacuerdo de fondo sobre qué se está estimando. El equipo puede decidir con más serenidad.

La decisión importante no fue pasar de 13 a 5. Fue descubrir que una historia aparentemente pequeña mezclaba exportación, permisos y diseño técnico del informe. Esa información vale más que una cifra cerrada deprisa.

Cómo facilitar la conversación sin burocracia

Un buen refinamiento necesita estructura, pero no ceremonia excesiva. Puedes usar esta secuencia en cinco pasos:

1. Presenta la historia en una frase. Objetivo, usuario y resultado esperado.
2. Haz visibles los criterios de aceptación. Si no existen, no empieces estimando; formula primero la duda principal.
3. Vota en privado. Esto reduce el efecto de anclaje de la primera voz fuerte. La FAQ de Stimo documenta que Scrum Master y Product Owner observan por defecto para reducir sesgos en la estimación, aunque participen aclarando contexto y facilitando decisiones.
4. Revela y mira la forma de los votos. No mires solo la cifra final; compara mediana, media y dispersión si la herramienta lo muestra.
5. Pregunta por supuestos, no por justificaciones. “¿Qué incluiste?” funciona mejor que “¿por qué votaste tan alto?”.

Una regla útil para el Scrum Master o facilitador: limita la primera conversación posterior al revelado a los dos extremos. No porque el resto no importe, sino porque los extremos suelen contener los supuestos que explican la dispersión. Después, resume en voz alta:

• “Hemos descubierto una dependencia”.
• “Estamos mezclando dos trabajos”.
• “Faltan criterios de aceptación”.
• “Parece que ahora compartimos el alcance; tiene sentido repetir”.

Ese resumen convierte la dispersión en aprendizaje accionable. DORA plantea su investigación como una forma de entender capacidades, métricas y formas de trabajo para mejorar continuamente. Sin trasladar conclusiones fuera de contexto, sí es razonable aplicar esa mentalidad al refinamiento: no medir para controlar la conversación, sino para aprender cómo trabaja el equipo.

Límites, errores comunes y cierre práctico

La dispersión no debe usarse como arma. Si cada voto alto se interpreta como resistencia o cada voto bajo como ingenuidad, el equipo aprenderá a esconder dudas. La estimación perderá su función más valiosa: revelar incertidumbre antes de comprometer trabajo.

Errores frecuentes:

• Promediar automáticamente. La media puede ser útil como referencia, pero no explica el desacuerdo.
• Forzar consenso por cansancio. Un número aceptado en silencio no equivale a entendimiento compartido.
• Repetir rondas sin cambios. Si nadie aprendió nada nuevo, la siguiente ronda solo añade desgaste.
• Convertir toda dispersión en división. A veces basta con aclarar un criterio o una dependencia.
• Invitar a demasiadas personas. Más voces no siempre significan más contexto; invita a quienes aportan información o estimación relevante.

Un cierre práctico para tu próxima sesión:

• Si la dispersión aparece por supuestos distintos, aclara.
• Si aparece porque la historia contiene varios trabajos, divide.
• Si aparece pero la conversación cambia el entendimiento común, repite.
• Si aparece porque falta información externa, aparca la estimación y define quién trae qué.

La madurez del equipo no se demuestra votando igual a la primera. Se demuestra usando el desacuerdo como dato temprano. Una ronda dispersa no es una pérdida de tiempo si evita meter en el Sprint una historia que nadie estaba entendiendo de la misma manera.

Fuentes consultadas

• Atlassian · Story points y estimación, para el marco de estimación relativa, story points y planning poker.
• Agile Manifesto, para el principio editorial de priorizar colaboración, interacción y adaptación sobre el seguimiento mecánico del proceso.
• DORA Research, como contexto sobre mejora continua de formas de trabajo y aprendizaje del sistema.
• Stimo · ayuda y Stimo · FAQ, para capacidades documentadas: votación privada, revelado, perfiles, resultados, mediana, media y dispersión.