Antes de otra ronda: cómo leer la dispersión del planning poker

Una ronda de planning poker rara vez se complica porque alguien haya elegido mal una carta. Se complica cuando el equipo descubre, demasiado tarde, que no estaba estimando la misma cosa.

La escena es conocida: una historia parece pequeña, se vota en privado, se revelan los resultados y aparecen cartas muy separadas. Una persona ve un ajuste trivial. Otra anticipa dependencias, pruebas cruzadas o una migración escondida. Alguien propone ‘hacer otra ronda’ para no bloquear el refinamiento. El problema es que una segunda ronda sin conversación suele producir una cifra más cómoda, no necesariamente una decisión mejor.

Atlassian presenta los story points y el planning poker como una práctica de estimación relativa y de equipo, no como una fórmula exacta. Y el Agile Manifesto recuerda que las interacciones y la respuesta al cambio pesan más que seguir un plan rígido. Leído así, un voto disperso no es una interrupción: es una señal útil de que el equipo todavía no comparte contexto suficiente.

La pregunta práctica no es ‘¿cómo llegamos rápido a un número?’, sino ‘¿qué nos está diciendo esta diferencia antes de comprometernos con el Sprint?’. Este marco ayuda a decidir cuándo aclarar, cuándo dividir y cuándo sí tiene sentido votar otra vez.

Qué significa una dispersión alta

La dispersión es la distancia entre las estimaciones del equipo. No hace falta convertirla en una métrica sofisticada para que sea útil. Basta con observar si las cartas se agrupan o si hay saltos relevantes entre ellas.

Una ronda con votos 3, 3, 5 y 5 suele indicar una diferencia razonable de percepción. Quizá el equipo necesita ajustar algún matiz, pero probablemente comparte una idea similar del alcance.

Una ronda con votos 2, 3, 13 y 21 dice otra cosa. Puede haber desacuerdo técnico, pero también puede haber información asimétrica: alguien conoce una dependencia, otra persona está pensando solo en la interfaz, QA está considerando datos de prueba complejos o UX ha detectado un flujo no mencionado.

La clave es no tratar todos los desacuerdos igual. Hay desacuerdos sanos, que afinan la estimación, y desacuerdos que revelan que la historia aún no está lista para estimarse.

Tres lecturas útiles:

• Dispersión por alcance: unas personas incluyen tareas que otras no habían entendido como parte de la historia.
• Dispersión por riesgo: alguien anticipa incertidumbre técnica, dependencia externa o validación difícil.
• Dispersión por criterio: el equipo usa referencias distintas para comparar tamaño, esfuerzo o complejidad.

En los tres casos, forzar consenso puede ocultar la causa real. La estimación queda cerrada, pero la duda sigue viva.

Un semáforo para decidir sin bloquear el refinamiento

Este semáforo no pretende ser una regla universal. Es una plantilla para facilitar conversaciones rápidas y consistentes. Cada equipo puede adaptarla a su escala, experiencia y tipo de producto.

Señal en la ronda	Qué puede indicar	Decisión recomendada
Votos muy próximos	Contexto compartido suficiente	Confirmar supuestos y cerrar estimación
Uno o dos votos alejados	Riesgo o interpretación no visible	Pedir a extremos que expliquen su lectura
Cartas en extremos de la escala	Alcance poco definido o historia demasiado grande	Aclarar alcance o dividir antes de estimar
Varias personas dudan o usarían ‘?’	Falta información relevante	No estimar todavía; formular la duda concreta
Media y mediana se separan mucho	Resultado arrastrado por valores extremos	Conversar el desacuerdo antes de aceptar un número

La comparación entre media y mediana puede ayudar, siempre que no se use como sustituto de la conversación. Si la mediana está en 5 pero la media sube por un 21, el número alto no debe ignorarse automáticamente. Puede ser ruido, pero también puede ser la única persona que ha visto el riesgo.

Si usas una herramienta de planning poker, busca que ayude a mantener esa lectura visible. En Stimo, por ejemplo, la ayuda documenta votos privados, revelado por el organizador, resumen por perfil y comparación de mediana y media. Su FAQ también explica el uso de la carta ‘?’ cuando falta información y la posibilidad de abrir otra ronda. La recomendación sigue siendo independiente de la herramienta: primero entender la dispersión, después votar de nuevo si procede.

Protocolo antes de votar otra vez

Cuando la ronda sale dispersa, la facilitación importa más que la aritmética. Esta secuencia evita que el equipo caiga en debate circular o consenso por cansancio.

1. Nombrar la señal sin juicio. ‘Tenemos una dispersión alta; antes de otra ronda, entendamos qué está viendo cada persona’.

2. Escuchar primero los extremos. Quien votó bajo explica qué asumió. Quien votó alto explica qué incluyó, qué riesgo vio o qué dependencia le preocupa. No se trata de defender la carta, sino de hacer visible el modelo mental.

3. Separar alcance, riesgo y desconocimiento. Pregunta: ‘¿Estamos discutiendo qué entra en la historia, qué puede salir mal o qué información nos falta?’.

4. Formular la duda en una frase. Por ejemplo: ‘No sabemos si la exportación debe incluir filtros avanzados’ o ‘No está claro si dependemos del equipo de datos’.

5. Decidir la acción mínima. Hay cuatro opciones: aclarar ahora, dividir la historia, marcar falta de información o lanzar otra ronda.

6. Votar de nuevo solo si cambió el contexto. Una nueva ronda tiene sentido cuando alguien aclaró un supuesto, se redujo alcance o se acordó qué queda fuera. Si nada cambió, la segunda ronda solo mide presión social.

Una pregunta sencilla ayuda mucho: ‘¿Qué tendría que ser cierto para que esta historia merezca la carta más baja? ¿Y qué tendría que ser cierto para que merezca la más alta?’.

Ejemplo aplicado: misma historia, tres lecturas

Ejemplo hipotético. Un equipo estima esta historia: ‘Como usuario, quiero descargar mis facturas en PDF para guardarlas fuera de la plataforma’.

Primera ronda: Developer vota 5, QA vota 13, UX vota 3 y otra persona vota 8. La tentación sería promediar o pedir otra ronda. Pero la dispersión apunta a contexto no compartido.

El facilitador pide explicar los extremos.

UX votó 3 porque asumió que solo hace falta añadir un botón en una pantalla ya existente. Developer votó 5 porque piensa reutilizar un servicio de generación de PDF. QA votó 13 porque no sabe si las facturas deben cubrir diferentes países, idiomas, impuestos y estados de pago. La persona que votó 8 incluyó permisos y trazabilidad de descargas.

El equipo descubre que no estaba estimando una misma historia. Había, al menos, tres decisiones escondidas:

• Alcance funcional: ¿descarga individual o descarga masiva?
• Reglas de negocio: ¿un solo país o varios formatos fiscales?
• Riesgo de validación: ¿qué combinaciones de factura deben probarse?

Opciones sobre la mesa:

• Aclarar con Producto y votar de nuevo si la respuesta llega en la sesión.
• Dividir en ‘descarga individual de factura existente’ y dejar ‘formatos fiscales avanzados’ para otra historia.
• Marcar la historia como no estimable todavía si la regla fiscal es imprescindible y nadie tiene la información.

Decisión razonable: dividir. El equipo acuerda estimar solo la descarga individual para facturas ya generadas y crear otra historia para variaciones fiscales. Ahora sí tiene sentido una segunda ronda, porque el contexto cambió. La nueva estimación ya no intenta tapar la dispersión: la usa para mejorar la definición.

Límites y errores comunes

La dispersión no siempre significa que la historia esté mal escrita. A veces refleja experiencia distinta, especialidades diferentes o memoria de incidentes anteriores. Por eso conviene evitar dos errores opuestos.

El primero es dramatizar cualquier diferencia. Si los votos están cerca, una breve conversación puede bastar. No todas las rondas necesitan convertirse en análisis de riesgos.

El segundo es cerrar por comodidad. Aceptar la mediana sin escuchar a quien votó alto puede dejar fuera una dependencia crítica. Aceptar el voto alto sin discutir puede inflar el Sprint con miedo no contrastado. La buena facilitación protege ambas cosas: velocidad y criterio.

También conviene no convertir el planning poker en una auditoría exhaustiva. El objetivo no es descubrir todo antes de empezar, sino decidir si hay suficiente contexto para comprometerse responsablemente. En términos ágiles, estimar no reemplaza la colaboración continua; la prepara.

Conclusión práctica: cuando aparezca dispersión, no preguntes primero ‘¿qué número cerramos?’. Pregunta ‘¿qué información no estamos compartiendo?’. Si la respuesta aclara el alcance, votad otra vez. Si revela una historia demasiado grande, dividid. Si muestra una duda real, usad ‘?’ o posponed la estimación hasta resolverla. El refinamiento mejora cuando la estimación deja de ser una negociación de cifras y se convierte en una conversación sobre contexto.

Fuentes consultadas

• Agile Manifesto: valores sobre individuos e interacciones, colaboración y respuesta al cambio.
• Atlassian · Story points y estimación: explicación de story points, estimación relativa y planning poker como práctica de equipo.
• Stimo · ayuda: documentación sobre votos privados, revelado, resultados, media y mediana.
• Stimo · preguntas frecuentes: uso de la carta ‘?’ cuando falta información y apertura de nuevas rondas.