Cómo hacer planning poker (paso a paso)

Planning poker es una técnica de estimación basada en consenso en la que cada integrante del equipo elige en privado una carta para el esfuerzo de una tarea, todos revelan al mismo tiempo, y el equipo discute cualquier desacuerdo hasta converger en una estimación compartida. Es la técnica de juicio experto más utilizada en la investigación sobre estimación ágil. Para hacerla necesitas un equipo, un conjunto de elementos para estimar y un deck de estimación, y luego sigues los siete pasos de abajo.

¿Qué es planning poker?

Planning poker (también llamado scrum poker o pointing poker) convierte la estimación en un juego corto y estructurado. En lugar de que la persona más ruidosa o más senior defina el número, todos se comprometen con una estimación en privado y la revelan a la vez. Esa única regla, la revelación simultánea, es lo que hace que la técnica funcione.

Por qué funciona: la ciencia de estimar en equipo

La razón por la que planning poker revela las cartas simultáneamente es evitar el anclaje (anchoring), el sesgo bien documentado por el cual el primer número mencionado arrastra la estimación de todos hacia él. En experimentos controlados, con solo mostrar un número arbitrario a profesionales de software antes de que estimaran, sus estimaciones se veían fuertemente arrastradas hacia él. El efecto fue grande, y un taller de capacitación diseñado para contrarrestarlo solo suavizó la atracción en lugar de eliminarla. El anclaje se ha identificado desde hace tiempo como una causa importante de que las estimaciones de software salgan demasiado bajas.

Estimar en grupo también ayuda. En un estudio que incorporó planning poker a tareas de un proyecto real, la estimación en la que el equipo acordó después de discutir fue menos optimista que simplemente promediar las conjeturas individuales de cada persona, y terminó más cerca del esfuerzo real. (Referencias completas en Fuentes, más abajo.)

Lo que necesitas antes de empezar

• Un equipo con las personas que harán el trabajo (típicamente de 3 a 9).
• Una lista priorizada de historias de usuario o tareas para estimar.
• Un deck de estimación (ver paso 2).
• Un facilitador (a menudo el Scrum Master) y alguien que pueda responder preguntas sobre cada elemento (a menudo el Product Owner).

Cómo hacer planning poker: 7 pasos

1. Arma la sala e invita al equipo. Crea una sesión y comparte el enlace. Con Planning Poker Web, una herramienta de planning poker gratuita, cualquiera puede unirse sin cuenta: abren el enlace y ya están dentro. Consejo de facilitación: acuerden el deck y una historia de referencia ("este bug pequeño = 2 puntos") antes de empezar, para que todos se calibren en la misma escala.
2. Elige un deck de estimación. Define la escala con la que votará el equipo (Fibonacci, tamaños de camiseta, etcétera). Consejo: mantén el mismo deck entre sprints para que tu velocidad siga siendo comparable.
3. Presenta la primera historia de usuario. El Product Owner lee el elemento y responde preguntas de aclaración. Sé breve, porque el detalle surge en la discusión. Tiempo sugerido: unos 2 minutos de presentación.
4. Todos votan al mismo tiempo. Cada persona selecciona en privado la carta que corresponde a su percepción del esfuerzo. Todavía no se dice ningún número en voz alta. Consejo: incluye a todos los que hacen el trabajo, testers y diseñadores, no solo a quienes desarrollan.
5. Revelen todas las cartas juntos. Cuando todos hayan votado, revelen simultáneamente. Este es el paso anti-anclaje: el voto de nadie fue influenciado por el de otra persona.
6. Discutan los valores atípicos. Si las estimaciones difieren, quienes votaron más alto y más bajo explican su razonamiento. Esto saca a la luz supuestos ocultos, tareas faltantes y riesgos, a menudo la parte más valiosa de la sesión. Tiempo sugerido: de 3 a 5 minutos. Si se extiende más, la historia probablemente es demasiado grande.
7. Vuelvan a votar hasta converger. Voten de nuevo después de la discusión. Repitan hasta que el equipo llegue a un número compartido. Regístrenlo y pasen al siguiente elemento. Consejo: "converger" significa suficientemente cerca para acordar, no idéntico, así que no persigan una carta unánime.

Un ejemplo práctico: estimando una historia de usuario

Supongamos que la historia es "El usuario puede restablecer su contraseña por correo electrónico". El Product Owner la lee, y un tester pregunta si la limitación de intentos (rate-limiting) está dentro del alcance (lo está). El equipo vota con un deck Fibonacci y revela:

El tester (8) explica: el flujo de restablecimiento necesita rate-limiting, trabajo en la plantilla de correo y casos límite para tokens expirados, nada de lo cual imaginaron los demás. Ese es exactamente el trabajo oculto que el planning poker está diseñado para sacar a la luz. Después de la discusión, el equipo vuelve a votar (5, 5, 8, 5) y acuerda 5. El número importa menos que el hecho de que todo el equipo ahora comparte la misma imagen del trabajo.

Planning poker remoto frente a presencial

La mecánica es idéntica. La facilitación cambia.

• Presencial: las cartas físicas funcionan, pero alguien tiene que transcribir los resultados y no hay historial automático. Presta atención a las personas que revelan lentamente e influyen en las demás.
• Remoto o distribuido: una sala en línea compartida es esencial. La herramienta garantiza la revelación (nadie ve los votos antes de tiempo), los resultados y el historial se capturan automáticamente, y el voto asíncrono permite que equipos en distintas zonas horarias estimen sin una llamada en vivo. Aquí es donde una herramienta como Planning Poker Web reemplaza por completo el mazo físico. Consulta nuestra guía de planning poker para equipos remotos para configuraciones en vivo y asíncronas.

Cuándo NO usar planning poker

Planning poker no siempre es la herramienta correcta. Sáltalo, o elige algo más rápido, cuando:

• El backlog es enorme (50+ elementos). Votar elemento por elemento es demasiado lento. Usa estimación por afinidad o el sistema de baldes para una primera pasada, y luego planning poker solo en los elementos inciertos.
• Una persona claramente es dueña del trabajo. Sin diversidad de perspectivas, el ritual grupal agrega poco frente a una estimación experta rápida.
• El equipo ya comparte un modelo mental claro. Para trabajo bien comprendido y repetitivo, las estimaciones rara vez divergen, así que la discusión tiene poco que revelar.
• Estás estimando para un roadmap de largo plazo, no un sprint. Un dimensionamiento aproximado (tamaños de camiseta) basta, y los puntos relativos precisos son esfuerzo desperdiciado tan lejos en el tiempo.

Ser honestos sobre esto genera confianza. Forzar el planning poker en la situación equivocada es como los equipos terminan resintiendo la estimación.

Escenarios difíciles (y cómo manejarlos)

• El equipo no converge después de dos rondas. La historia suele ser demasiado grande o vaga. Divídela, o devuélvela al Product Owner para que la aclare.
• Una persona domina la discusión. El voto privado ya limita esto. Refuérzalo pidiendo que hable primero quien votó más bajo, no la persona más senior.
• Alguien siempre vota con la mayoría. Pídele que vote antes de "leer la sala". En una herramienta, los votos quedan ocultos hasta la revelación, lo que elimina la tentación.
• Las estimaciones son sistemáticamente bajas. Esto es el optimismo y el anclaje en acción. Mantén una historia de referencia visible y compara los elementos nuevos con ella, en lugar de estimar en el vacío.

Planning poker frente a otras técnicas de estimación

Errores comunes que evitar

• Decir un número antes de la revelación, lo que reintroduce el anclaje.
• Estimar en horas en lugar de puntos relativos. El dimensionamiento relativo es más rápido y menos sesgado.
• Promediar en lugar de discutir. La discusión es el objetivo, y el número es el subproducto.
• Dejar que una persona domine. El voto privado existe precisamente para evitar esto.
• Votar sin parar. Perseguir una carta unánime desperdicia tiempo, así que "suficientemente cerca para acordar" es la meta.

Glosario: términos del planning poker

• Story point (punto de historia): una unidad de esfuerzo relativo (no horas), que combina complejidad, incertidumbre y volumen de trabajo.
• Deck: el conjunto de cartas con el que vota el equipo (por ejemplo, Fibonacci, tamaños de camiseta).
• Velocidad (velocity): cuántos puntos completa un equipo por sprint, usado para pronosticar, no para comparar equipos.
• Anclaje (anchoring): el sesgo por el cual el primer número mencionado arrastra las demás estimaciones hacia él, la razón por la que los votos se revelan simultáneamente.
• Valor atípico (outlier): el voto más alto o más bajo, cuyo razonamiento el equipo discute primero.
• Historia de referencia: un elemento ya estimado con el que el equipo compara las historias nuevas, para mantener la escala estable.

Preguntas frecuentes

¿Cuánto dura una sesión de planning poker?

Para un backlog normal de sprint, de 30 a 60 minutos. Un solo elemento suele llevar de 1 a 3 minutos, a menos que las estimaciones diverjan y necesiten discusión.

¿Cuántas personas deberían participar?

Típicamente las 3 a 9 personas que realmente harán el trabajo. Menos de tres pierde el beneficio de las perspectivas diversas, y más de nueve ralentiza la discusión.

¿Qué deck deberíamos usar?

Fibonacci (0, 1, 2, 3, 5, 8, 13 en adelante) es el estándar más común porque los intervalos crecientes reflejan la incertidumbre creciente en elementos más grandes. Los tamaños de camiseta son adecuados para un dimensionamiento inicial y aproximado.

¿Por qué todas las cartas se revelan al mismo tiempo?

Para evitar el anclaje, el sesgo por el cual el primer número dicho arrastra la estimación de todos hacia él. La revelación simultánea mantiene cada voto independiente.

¿Estimamos en horas o en puntos?

Se recomiendan los puntos relativos (story points). Son más rápidos de acordar y menos propensos al sesgo optimista que muestran las estimaciones en horas en la investigación.

¿Qué pasa si el equipo no logra ponerse de acuerdo?

Deja que quienes votaron más alto y más bajo expliquen, y vuelvan a votar. Si aun así no converge, el elemento probablemente es demasiado grande o vago, así que divídelo o devuélvelo para aclararlo.

¿Se puede hacer planning poker de forma asíncrona?

Sí. Con una herramienta en línea, los integrantes del equipo votan en su propio tiempo y se revela una vez que todos han votado, lo cual es útil para equipos distribuidos en distintas zonas horarias. El beneficio anti-anclaje se mantiene, porque los votos permanecen ocultos hasta la revelación.

¿Quién debería participar, y debería votar el Scrum Master?

Todos los que hacen el trabajo (desarrolladores, testers, diseñadores). El Scrum Master suele facilitar en lugar de votar, y el Product Owner responde preguntas pero no estima.

¿Planning poker es lo mismo que scrum poker?

Sí. "Scrum poker" y "pointing poker" son sinónimos comunes de la misma técnica.

Fuentes

1. Moløkken-Østvold, Haugen & Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106 a 2117.
2. Mahnič & Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086 a 2095.
3. Jørgensen & Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula.
4. Løhre & Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software.
5. Shepperd et al. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919.