Dispersión en planning poker: cómo decidir si falta contexto antes de estimar

Cuando una ronda de planning poker termina con votos muy separados, el problema no siempre es que el equipo esté “estimando mal”. A veces la dispersión está diciendo algo más importante: varias personas no están estimando la misma historia.

Un 2, un 5 y un 13 pueden parecer una discusión sobre esfuerzo. Pero también pueden esconder tres lecturas distintas: una persona asumió que la validación ya existe, otra incluyó cambios de interfaz y otra detectó una dependencia externa. Si el equipo fuerza un consenso rápido, la estimación final puede quedar limpia en la herramienta y confusa en la práctica.

La utilidad de la dispersión no está en calcular una cifra perfecta, sino en decidir qué conversación toca ahora. Atlassian presenta los story points y el planning poker como prácticas de estimación relativa y calibración entre personas, no como una medición exacta. Y el Agile Manifesto recuerda una prioridad útil para este momento: valorar más la colaboración y la respuesta al cambio que seguir un plan rígido.

Esta guía propone una forma práctica de leer la dispersión: cuándo hacer otra ronda, cuándo aclarar alcance, cuándo dividir la historia y cuándo aplazar la estimación.

Qué significa realmente una ronda dispersa

La dispersión aparece cuando los votos quedan lejos entre sí. No hace falta convertirla en una fórmula estadística compleja para que sea útil. En refinamiento, basta observar tres señales:

• Hay saltos grandes entre votos: por ejemplo, 2, 3, 13.
• Aparecen varias cartas “?” o personas que declaran no tener contexto suficiente.
• La conversación posterior no converge en una duda común, sino en varias interpretaciones del trabajo.

La dispersión puede ser productiva. Un voto alto puede revelar una dependencia que nadie había considerado. Un voto bajo puede mostrar que alguien conoce una solución simple. El problema aparece cuando el equipo trata esa diferencia como una molestia que hay que cerrar rápido.

La pregunta útil no es “¿qué número gana?”, sino: “¿qué información explica la diferencia?”. Si esa información aparece y el alcance queda compartido, una segunda ronda tiene sentido. Si no aparece, repetir votos solo añade movimiento sin aprendizaje.

En herramientas como Stimo, la votación privada ayuda a que cada perfil vote sin arrastre inicial del grupo, y los resultados muestran referencias como media y mediana por perfil. Según la ayuda de Stimo, el organizador revela los votos, conversa los desacuerdos y puede abrir una nueva ronda. La parte importante no es la pantalla: es usar ese momento para nombrar la duda antes de volver a votar.

Marco de decisión: de la dispersión a la siguiente acción

Después de revelar votos, evita saltar directamente a “votemos otra vez”. Usa este marco de cuatro salidas.

Señal después de revelar	Qué puede significar	Decisión recomendada
Votos distintos, pero una sola duda clara	Hay desacuerdo productivo sobre complejidad o riesgo	Aclarar la duda y hacer otra ronda
Votos muy separados y varias interpretaciones del alcance	El equipo no está estimando lo mismo	Reformular alcance o criterios antes de votar
Varios “?” o silencio al pedir explicación	Falta información básica para estimar	Aplazar la estimación y traer contexto
Votos altos por partes independientes del trabajo	La historia mezcla piezas separables	Dividir la historia y estimar cada parte

Este marco evita dos errores frecuentes: cerrar con una media que nadie defiende o alargar la discusión sin decidir qué información falta.

Una regla práctica: antes de cualquier segunda ronda, cada extremo debe explicar su hipótesis en una frase. No una defensa larga. Una frase concreta:

• “Voté 13 porque asumí migración de datos.”
• “Voté 3 porque pensé que reutilizábamos el componente actual.”
• “Puse ? porque no sé si Legal tiene que revisar el texto.”

Si esas frases hablan del mismo problema, el equipo puede resolverlo y votar otra vez. Si hablan de problemas distintos, la historia todavía necesita refinamiento.

Checklist para facilitar la conversación sin convertirla en debate circular

El Scrum Master, Product Owner o facilitador puede usar esta secuencia en menos de diez minutos.

1. Revela y observa el patrón, no solo el número final. Mira extremos, cartas “?” y agrupaciones. Si la mayoría está entre 3 y 5 pero hay un 13, ese 13 merece contexto, no descarte automático.

2. Pide hipótesis, no justificaciones. La pregunta cambia el tono: “¿Qué asumiste para votar eso?” funciona mejor que “¿por qué votaste tan alto?”.

3. Separa incertidumbre de desacuerdo. Desacuerdo es: “entiendo la historia, pero creo que es más compleja”. Incertidumbre es: “no sé qué incluye exactamente”. La primera puede resolverse con calibración; la segunda requiere información.

4. Identifica la decisión mínima. No hace falta resolver todo el diseño. Hace falta decidir si la historia es estimable ahora. La conversación debe terminar en una de estas acciones: otra ronda, aclarar, dividir o aplazar.

5. Registra el supuesto clave. Si el equipo estima tras aclarar, deja visible la condición que hizo posible la estimación: “No incluye migración histórica” o “QA automatiza solo el flujo principal”.

6. No castigues la duda. La carta “?” existe para indicar falta de información. Las preguntas frecuentes de Stimo explican que Product Owner y Scrum Master pueden aclarar contexto y facilitar decisiones aunque no sumen esfuerzo técnico por defecto. Esa separación ayuda a que preguntar no parezca bloquear.

Ejemplo aplicado: una historia de filtros en el panel

Ejemplo hipotético. Un equipo estima esta historia:

“Como responsable de soporte, quiero filtrar tickets por prioridad y fecha para revisar incidencias críticas.”

Primera ronda: Developer vota 5, QA vota 8, UX vota 3, Otro vota ?. La dispersión no es enorme en apariencia, pero las explicaciones revelan lecturas distintas.

• Developer votó 5 porque asumió que el endpoint ya permite filtrar por ambos campos.
• QA votó 8 porque incluyó pruebas de combinaciones, permisos y datos históricos.
• UX votó 3 porque pensó en añadir controles sobre un patrón ya existente.
• Otro votó ? porque no sabe si prioridad es un campo estándar o configurable por cliente.

Opciones del equipo:

1. Hacer otra ronda inmediatamente.
2. Promediar y cerrar en 5 u 8.
3. Aclarar dos supuestos: disponibilidad del endpoint y naturaleza del campo prioridad.
4. Dividir la historia en filtro por prioridad y filtro por fecha.

Decisión razonable: no votar otra vez todavía. La carta “?” y las hipótesis distintas indican falta de contexto, no solo diferencia de criterio. El Product Owner confirma que prioridad es estándar para todos los clientes, pero el equipo descubre que el endpoint solo filtra por fecha. Entonces reformulan el alcance: primera historia, filtro por fecha con interfaz y pruebas; segunda historia, filtro por prioridad cuando backend esté preparado.

Resultado: se estiman dos piezas más claras. La dispersión no fue un fallo de estimación; fue la señal que evitó mezclar frontend listo, backend pendiente y reglas de negocio ambiguas en un único número.

Errores comunes al interpretar la dispersión

Usar la media como cierre automático. La media puede ser útil como referencia, pero no sustituye la conversación. Si los votos están lejos porque las personas asumieron alcances distintos, promediar solo esconde el problema.

Confundir consenso con silencio. Una segunda ronda con votos más parecidos puede significar alineación. También puede significar cansancio o presión por avanzar. Por eso conviene pedir primero la duda principal.

Tratar el voto alto como pesimismo. A veces el voto alto contiene el riesgo que hará fallar el Sprint. Pide el supuesto detrás del número antes de descartarlo.

Dividir siempre que haya dispersión. Dividir ayuda cuando la historia mezcla trabajos separables. Si la dispersión viene de una dependencia o de un criterio de aceptación ambiguo, quizá baste con aclarar.

Aplazar sin definir qué falta. Posponer puede ser correcto, pero debe terminar con una pregunta asignada: “confirmar límite de datos”, “validar dependencia con pagos” o “decidir si entra accesibilidad avanzada”. Aplazar sin pregunta solo mueve la confusión a la siguiente sesión.

Conclusión práctica

La dispersión en planning poker no debe tratarse como ruido. Es una invitación a preguntar qué está viendo cada persona que las demás no ven.

La próxima vez que una ronda termine con votos separados, prueba esta secuencia: pide una hipótesis por voto extremo, identifica si hay desacuerdo o falta de contexto, y elige una salida explícita: otra ronda, aclarar, dividir o aplazar. Si el equipo aprende algo nuevo antes de cambiar el número, la dispersión ya cumplió su función.

Fuentes consultadas

• Atlassian · Story points y estimación, como referencia sobre estimación relativa, story points y planning poker.
• Agile Manifesto, para anclar la recomendación en colaboración y respuesta al cambio.
• Stimo · ayuda, para contrastar el flujo de votos privados, revelado de resultados y nueva ronda.
• Stimo · preguntas frecuentes, para el contexto de perfiles, roles observadores y aclaración durante la sesión.