Cómo realizar Planning Poker paso a paso

Planning Poker funciona cuando las cartas fomentan una conversación útil, no cuando el equipo intenta adivinar el número “correcto”. Una buena sesión ofrece a todos el mismo contexto del backlog, protege el juicio independiente hasta la revelación y usa estimaciones distintas para descubrir suposiciones antes de que el trabajo entre en un sprint.

Esta guía te proporciona una agenda repetible para un facilitador, un Product Owner o responsable del backlog, y las personas que ayudarán a entregar el trabajo.

En esta guía

• La versión corta
• Preparar el backlog y los participantes
• Utilizar una agenda práctica de 45 minutos
• Calibrar y presentar cada ítem
• Votar, revelar y discutir la dispersión
• Revotar, dividir o pausar
• Revisar el ejemplo de cinco ítems
• Evitar errores comunes
• Usar la lista de comprobación del facilitador

La versión corta

Para cada ítem del backlog:

1. Explica el resultado para el usuario, el alcance y las condiciones de aceptación.
2. Permite que el equipo haga preguntas aclaratorias.
3. Pide a cada estimador que elija una carta en privado.
4. Revela todas las cartas al mismo tiempo.
5. Si la dispersión es significativa, escucha las razones detrás de los votos más bajos y más altos.
6. Aclara el ítem, divídelo si es necesario y vota de nuevo.
7. Registra la estimación que el equipo acuerda usar y pasa al siguiente ítem.

Planning Poker es una práctica de estimación, no un evento obligatorio de Scrum. La guía actual de Scrum deja los métodos de dimensionamiento al equipo, enfatizando que quienes realizan el trabajo son responsables de estimar los ítems del Product Backlog.

Antes de la sesión: prepara trabajo que pueda ser discutido

Una sala de votación no puede compensar un ítem del backlog que nadie entiende. Prepara un conjunto pequeño de ítems a corto plazo en lugar de traer todo el backlog.

Para cada ítem, asegúrate de que el equipo pueda ver:

• el resultado para el usuario o negocio;
• lo que está incluido y lo que se excluye explícitamente;
• condiciones de aceptación o un ejemplo del comportamiento esperado;
• dependencias conocidas, restricciones y sistemas afectados;
• preguntas abiertas que puedan cambiar el tamaño;
• un enlace a diseños de soporte o contexto técnico cuando sea relevante.

No elimines toda incertidumbre antes de la estimación. La incertidumbre es parte de lo que la estimación debe revelar. Pero el equipo necesita suficiente contexto para distinguir un pequeño detalle de implementación de una decisión de producto sin resolver.

Elige una escala antes de comenzar la votación

Muchos equipos usan una secuencia tipo Fibonacci como 1, 2, 3, 5, 8, 13, 21. Las brechas crecientes reflejan que la confianza usualmente disminuye a medida que el trabajo es mayor o menos comprendido. Agilo también soporta otras escalas integradas y conjuntos de cartas personalizados.

Trata los puntos de historia como tamaños relativos específicos del equipo. Un 5 es útil porque el equipo entiende cómo se compara con su propio 2 u 8; no es un número universal de horas y no debe copiarse entre equipos como tabla de conversión.

Invita a las personas adecuadas

Las personas que se espera entreguen el trabajo deben votar. El Product Owner o responsable del backlog explica la intención, prioridad y concesiones. Un facilitador mantiene el ritmo, da espacio a los participantes más callados y evita que la discusión se convierta en una negociación hacia un número preferido.

En Agilo, los participantes necesitan cuentas para unirse a una sala y votar. Crea la sala antes de la sesión, selecciona el sistema de estimación, añade o importa los primeros ítems y comparte la invitación con tiempo suficiente para que todos se unan.

Interfaz actual de Agilo: ocho participantes ficticios han votado, mientras que cada estimación permanece oculta hasta la revelación.

Una agenda práctica de 45 minutos

Usa esto como punto de partida y ajústalo según el número y la complejidad de los ítems.

Cinco ítems bien preparados suelen ser más útiles que quince votos apresurados. Si el equipo necesita repetidamente un largo descubrimiento del producto durante la sesión, devuelve esos ítems a refinamiento y mantén Planning Poker enfocado en trabajo listo para una conversación de dimensionamiento.

Paso 1: calibrar con una referencia familiar

Comienza con un ítem completado recientemente cuya forma el equipo recuerde. No estás reescribiendo la historia para obtener una puntuación perfecta. Estás dando a la sala una comparación compartida: “Este ítem tuvo un cambio en la interfaz, un cambio en la API y cobertura de pruebas conocida; para nosotros representa un 3.”

Usa referencias del mismo equipo y área de producto cuando sea posible. Un 5 del equipo móvil y un 5 del equipo de plataforma no tienen que significar lo mismo.

Para una escala de referencia concreta, compara estos seis ejemplos de puntos de historia, incluyendo los límites de aceptación que hacen un ítem más pequeño o más grande.

Paso 2: presentar un ítem del backlog

El responsable del backlog explica el resultado y los límites en unos minutos. Evita repasar una implementación propuesta como si ya estuviera decidida. Los desarrolladores pueden ver un camino más simple o una dependencia que cambia toda la estimación.

Una apertura útil suena así:

Un usuario autenticado puede exportar el informe actual en CSV. Esta ronda incluye los filtros visibles de la tabla, pero no las exportaciones programadas ni el mapeo de columnas personalizado.

Luego permite que el equipo haga preguntas. Si una pregunta cambia el alcance, actualiza el ítem antes de votar.

Paso 3: votar en privado y revelar juntos

Cada estimador selecciona una carta sin ver las elecciones de los demás. Las votaciones ocultas reducen el anclaje al primer número, a la persona más senior o a la expectativa del facilitador.

Revela solo después de que todos hayan votado. Agilo puede revelar las cartas manual o automáticamente tras que todos los participantes hayan votado, según la configuración de la sala. El facilitador también puede usar el temporizador de sala cuando el equipo necesite un límite suave para preguntas o votación.

No apresures a las personas que eligen ?. Esa carta es una evidencia útil: el ítem puede carecer de contexto, estar fuera del área de experiencia de alguien o contener una suposición que vale la pena hacer visible.

Paso 4: discute la dispersión, no cada número

Si los votos se agrupan alrededor de valores contiguos, el equipo puede necesitar solo una breve confirmación. Si la dispersión es amplia —por ejemplo, 3, 3, 5, 8, 13— comienza con el razonamiento detrás de las estimaciones más bajas y más altas.

Haz preguntas como:

• ¿Qué incluye el 13 que el 3 no?
• ¿Hay alguna dependencia o modo de fallo que otros hayan pasado por alto?
• ¿Estamos estimando las mismas condiciones de aceptación?
• ¿Alguien está asumiendo infraestructura reutilizable que aún no existe?
• ¿Dividir el ítem eliminaría la incertidumbre principal?

El objetivo es el entendimiento compartido. El consenso puede surgir después, pero forzar a todos hacia la misma carta sin resolver la diferencia subyacente derrota el ejercicio.

Cuando una persona vota 3 y otra 13: buenas noticias: las cartas no están rotas. El equipo acaba de encontrar la conversación que buscaba. 😅

Interfaz actual de Agilo tras la revelación: la dispersión de 3 a 8 es un estímulo para comparar suposiciones. El promedio de 5.3 es contexto, no una respuesta final automática.

Paso 5: aclarar, dividir o votar de nuevo

Tras la discusión, elige una de tres opciones:

1. Revotar. El ítem está claro y la nueva información cambió la visión del equipo.
2. Dividir el ítem. La estimación es grande porque varios resultados o pasos técnicos están agrupados.
3. Pausar la estimación. Se debe resolver primero una decisión de producto, dependencia o investigación.

Agilo admite una ronda adicional de votación, pero no elige la estimación final para el equipo. El facilitador y los estimadores siguen decidiendo qué valor refleja su entendimiento compartido.

Paso 6: registra el resultado y continúa

Una vez que el equipo acuerde la estimación que usará, regístrala con el ítem del backlog y selecciona el siguiente mientras la sesión aún tiene impulso. Si usas la integración de Agilo con Jira, puedes importar issues de Jira con su contexto y devolver la estimación seleccionada cuando la sincronización esté configurada.

Mantén una nota aparte para preguntas pendientes. No ocultes un alcance no resuelto detrás de un número solo para terminar la lista.

Ejemplo práctico: cinco ítems del backlog

Los valores a continuación pertenecen a un equipo de producto ficticio que usa sus propios ítems de referencia. Son ejemplos de razonamiento, no una clave universal de respuestas.

Considera el ítem de los widgets. Los votantes bajos imaginaron solo un cambio en el diseño de escritorio. Los votantes altos incluyeron gestos móviles, orden persistente, accesibilidad por teclado y migración de diseños existentes. Ningún promedio solucionaría esa discrepancia. Dividir el ítem hizo explícito el alcance y produjo dos conversaciones más significativas.

Errores comunes que debilitan la sesión

Tratar el promedio como la respuesta

Un promedio puede ocultar dos interpretaciones incompatibles. Discute primero la dispersión. La estimación final debe reflejar el trabajo comprendido, no una comodidad aritmética.

Permitir que la persona con más rango vote en voz alta

Cuando un número se pronuncia, las votaciones posteriores tienden a girar en torno a él. Mantén las cartas ocultas hasta revelarlas y pide la justificación tras la votación independiente.

Debatir la implementación antes de que el resultado esté claro

La discusión técnica es valiosa, pero solo después de que todos entiendan qué debe lograr el ítem. De lo contrario, el equipo puede estimar productos distintos.

Forzar una estimación para un ítem no preparado

“Necesitamos un número hoy” no elimina una dependencia. Marca la pregunta, asigna un responsable y vuelve cuando la decisión pendiente esté disponible.

Comparar personas o equipos por puntos de historia

Los puntos son una herramienta local de planificación. Convertirlos en una meta de rendimiento fomenta números inflados y reduce la utilidad de las estimaciones.

Lista de verificación para el facilitador

Antes de la reunión:

• elige 5–8 ítems a corto plazo;
• añade contexto y enlaces de aceptación;
• crea la sala y selecciona el conjunto de cartas;
• confirma quién explicará los ítems y quién votará;
• elige un ítem de referencia familiar.

Durante cada ronda:

• mantén las votaciones ocultas hasta que todos estén listos;
• escucha las razones de votos bajos y altos cuando la dispersión importe;
• actualiza el ítem cuando cambien supuestos;
• revota, divide o pausa, en lugar de forzar un acuerdo;
• registra la estimación seleccionada y cualquier responsable de seguimiento.

Después de la reunión:

• asegúrate de que las estimaciones sean visibles en el backlog;
• resuelve los ítems pausados antes de que lleguen a la planificación del sprint;
• revisa la escala solo cuando el equipo la encuentre consistentemente inútil.

Ejecuta el flujo de trabajo en Agilo

Agilo Planning Poker mantiene el contexto del backlog, votación privada, revelación simultánea, rondas repetidas y la estimación seleccionada en una sola sala. Puedes añadir trabajo manualmente o importar issues de Jira, usar un conjunto de cartas predeterminado o personalizado, y pasar directamente al siguiente ítem tras el acuerdo del equipo.

Crea una sala de Planning Poker cuando tus ítems del backlog y participantes estén listos.

Fuentes y lecturas adicionales

• Agile Alliance: Planning Poker — patrón básico de voto privado, revelación simultánea, discusión y rondas adicionales.
• La guía oficial de Scrum — definición actual de Scrum y responsabilidades en la estimación del Product Backlog.