Planning poker para cerrar una duda, no para alargar el refinamiento
Una historia pequeña no siempre es una historia clara. Puede tener poco alcance, una interfaz sencilla o una regla de negocio acotada y, aun así, bloquear al equipo durante veinte minutos: una persona ve una dependencia,
Publicado el
Una historia pequeña no siempre es una historia clara. Puede tener poco alcance, una interfaz sencilla o una regla de negocio acotada y, aun así, bloquear al equipo durante veinte minutos: una persona ve una dependencia, otra asume un comportamiento distinto, QA necesita saber qué ocurre en un borde y UX duda de un estado vacío.
En esos casos, el problema no es “estimar mejor” en abstracto. El problema es decidir qué duda merece conversación, cuál puede resolverse con un criterio de aceptación y cuándo la historia debe volver a trabajarse antes de entrar al Sprint.
El planning poker ayuda cuando se usa como detector de entendimiento compartido. No porque el número final sea mágico, sino porque la votación privada saca a la luz diferencias que en una conversación abierta pueden quedar tapadas por la primera opinión fuerte. Bien facilitado, permite convertir una estimación dispersa en una decisión: aclarar, dividir, aceptar el riesgo o reestimar con un nuevo entendimiento.
Cambia la pregunta: de “¿cuántos puntos?” a “¿qué estamos asumiendo?”
En historias pequeñas, el equipo suele caer en una trampa: como “parece poco”, se intenta cerrar rápido. Eso puede funcionar cuando el contexto es compartido, pero no cuando cada perfil está estimando una versión distinta de la historia.
Antes de votar, conviene dedicar un minuto a fijar el marco:
- Qué objetivo debe cumplir la historia.
- Qué queda dentro y fuera del alcance.
- Qué criterios de aceptación son visibles.
- Qué dependencias o riesgos se conocen.
- Qué duda concreta se quiere cerrar en la sesión.
La última pregunta es clave. Una ronda de planning poker no debería abrir todas las conversaciones posibles. Debería ayudar a resolver una tensión específica: “¿esto incluye validación en backend?”, “¿probamos solo el flujo feliz o también errores?”, “¿hay que tocar el diseño responsive?”, “¿dependemos de otro equipo?”.
Este enfoque encaja bien con los valores ágiles: las herramientas son útiles cuando apoyan la interacción, no cuando sustituyen la conversación. El número es una consecuencia; el aprendizaje compartido es el trabajo real.
Usa la primera ronda para encontrar la duda dominante
La primera votación debería ser privada. Si las personas votan después de escuchar una estimación dominante, se pierde una de las mayores ventajas del planning poker: detectar diferencias de criterio antes de que el grupo se acomode.
Una secuencia simple puede ser:
- El Product Owner o quien tenga contexto presenta la historia.
- El equipo confirma el objetivo y los criterios visibles.
- Cada perfil votante estima en privado.
- El facilitador revela los votos.
- El equipo observa la dispersión antes de explicar posiciones.
Si los votos están cerca, quizá solo haga falta confirmar un supuesto menor. Si hay mucha distancia, evita saltar directamente a negociar el número medio. La pregunta útil es: “¿qué vio la persona que votó más alto que el resto no vio?” y también “¿qué está asumiendo quien votó más bajo?”.
En historias pequeñas, la diferencia entre una estimación baja y una alta suele venir de tres fuentes:
- Alcance implícito: alguien incluye un comportamiento que no estaba escrito.
- Riesgo técnico o de validación: alguien conoce una dependencia, deuda o borde no discutido.
- Diferencia de calidad esperada: cada perfil imagina pruebas, diseño, accesibilidad o revisión con distinto nivel de detalle.
El objetivo de la conversación no es convencer al otro de bajar su voto. Es decidir si la historia que se está estimando es realmente la misma para todos.
Decide con una regla simple: aclarar, dividir o reestimar
Después de revelar votos, el facilitador necesita evitar dos extremos: cerrar en falso para avanzar o convertir la ronda en un análisis infinito. Una buena práctica es usar una regla de decisión visible.
Puedes trabajar con tres salidas:
1. Aclarar y mantener la historia
Úsalo cuando la duda se resuelve añadiendo una frase concreta al criterio de aceptación o confirmando un límite de alcance.
Ejemplo genérico: la historia dice “el usuario puede descargar el informe”. El equipo duda si incluye filtros avanzados. Se decide que esta historia solo cubre la descarga del informe ya filtrado en pantalla. Se añade el criterio y se vuelve a votar si el cambio afecta al entendimiento.
2. Dividir la historia
Úsalo cuando la dispersión revela dos trabajos con incertidumbres distintas o valor separable.
Ejemplo genérico: una historia incluye mostrar un resumen y exportarlo. El resumen está claro, pero la exportación depende de formato, permisos y validaciones. Separarlas permite avanzar con lo claro y refinar lo dudoso sin arrastrar todo el bloque.
3. Reestimar tras la conversación
Úsalo cuando la historia sigue siendo la misma, pero el equipo cambió su entendimiento. En ese caso, una segunda ronda no es burocracia: es la forma de comprobar si la conversación redujo la ambigüedad.
Esta segunda ronda tiene sentido especialmente cuando hubo mucha dispersión inicial o cuando apareció información nueva. Si la dispersión persiste, probablemente no estás ante un problema de estimación, sino de definición, dependencia o riesgo no resuelto.
El papel del Scrum Master y del Product Owner en la ronda
El planning poker funciona mejor cuando cada rol aporta sin sesgar.
El Product Owner debería aclarar intención, valor, límites de alcance y prioridades. No necesita defender una estimación baja para “hacer entrar” la historia. Si una aclaración cambia el trabajo, el equipo debe poder ajustar su voto.
El Scrum Master facilita el ritmo y protege la calidad de la conversación. Puede ayudar con preguntas como:
- “¿Estamos estimando la misma versión de la historia?”
- “¿Qué supuesto explica la estimación más alta?”
- “¿Esta duda se resuelve con un criterio o exige dividir?”
- “¿Hace falta otra ronda porque cambió el entendimiento?”
Los perfiles técnicos, de QA, UX u otros especialistas aportan la estimación desde su perspectiva. En herramientas como Stimo, la sala permite que los perfiles votantes estimen en privado y que el organizador revele resultados cuando todos han votado. También es posible usar “?” cuando falta información, una señal útil para no convertir incertidumbre real en un número aparentemente preciso.
Lo importante no es que cada rol siga una ceremonia perfecta, sino que el equipo mantenga una conversación enfocada y tome una decisión explícita.
Errores comunes que alargan historias pequeñas
Confundir consenso con unanimidad. El equipo no necesita que todas las personas piensen igual. Necesita entender por qué difieren y decidir si la diferencia importa.
Promediar demasiado pronto. Si hay dispersión, calcular un punto intermedio puede ocultar el desacuerdo. Primero conversa el motivo; después estima.
Votar sin criterios visibles. Si nadie puede ver los criterios de aceptación, cada voto puede estar respondiendo a una historia distinta.
Usar “?” como bloqueo indefinido. Marcar falta de información es sano, pero debe conducir a una acción: aclarar con alguien, añadir criterio, dividir o sacar la historia del refinamiento.
Repetir rondas sin nueva información. Una segunda ronda tiene sentido si cambió el entendimiento. Si solo se repite para forzar convergencia, el equipo aprende a ceder, no a estimar mejor.
Cierre práctico
Para historias pequeñas, el planning poker no debería convertirse en una discusión sobre puntos. Su mejor uso es mucho más concreto: hacer visibles los supuestos, cerrar la duda principal y decidir el siguiente paso.
Una buena ronda termina con una de estas frases:
- “Añadimos este criterio y la historia queda lista”.
- “La partimos porque hay dos trabajos distintos”.
- “Reestimamos porque ahora entendemos otra cosa”.
- “No está lista; falta información concreta”.
Si el equipo sale con una decisión así, la estimación ya cumplió su función.
Fuentes consultadas
¿Listo para ponerlo en práctica?
Crear una sala en Stimo