Cómo se juega al planning poker

El planning poker es una forma de estimar en equipo con cartas. Cada participante tiene la misma baraja, se comenta una historia de usuario y todos muestran su carta al mismo tiempo. Si las cartas coinciden más o menos, se anota el número. Si no, quienes votaron en los extremos cuentan qué ven y se repite la votación. La gracia está en que nadie conoce la cifra de los demás antes de elegir la suya, cosa que en una reunión de estimación de toda la vida casi nunca pasa.

De Delphi a las cartas

La idea de fondo es bastante anterior al desarrollo ágil. En los años cincuenta y sesenta, la RAND Corporation desarrolló el método Delphi: varios expertos contestan por separado y de forma anónima, reciben un resumen de lo que ha dicho el grupo y ajustan su respuesta en rondas sucesivas. En los setenta, Barry Boehm y John Farquhar lo llevaron a la estimación de software con el nombre de Wideband Delphi, que añadía una conversación entre ronda y ronda.

El salto a las cartas llegó en 2002, cuando James Grenning publicó un artículo corto en el que proponía el planning poker para que la planificación de entregas en XP no se alargara sin fin. Tres años después, Mike Cohn le dedicó un apartado dentro del capítulo sobre técnicas de estimación de Agile Estimating and Planning (2005). Ese libro, y las barajas que Cohn distribuyó, hicieron mucho por que la técnica llegara a equipos de todo el mundo. Hoy se usa sobre todo para poner puntos de historia al backlog.

Una ronda, de principio a fin

Antes de empezar, cada persona necesita una baraja. La habitual es la de Fibonacci modificada (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?» y ☕); en la página de la baraja Fibonacci se explica por qué los números saltan así. Con eso, una ronda tiene esta forma:

1. Alguien, normalmente el product owner, presenta la historia y los criterios de aceptación.
2. El equipo pregunta hasta entender qué se pide. No hace falta diseñar la solución en la reunión, solo saber lo bastante para darle un tamaño.
3. Cada uno elige carta sin decir nada ni hacer gestos.
4. Se revelan todas a la vez.
5. Si los números están cerca, por ejemplo tres 5 y un 3, se comenta en una frase y se anota uno.
6. Si están lejos, habla primero quien puso la carta más alta y después quien puso la más baja. Luego se vuelve a votar.

Con dos rondas suele bastar. Si en la tercera las cartas siguen dispersas, seguir votando no arregla nada: falta información o la historia es demasiado grande y hay que dividirla.

Quién vota

Votan las personas que van a hacer el trabajo: desarrollo, pruebas, diseño si forma parte del equipo. El product owner, en la mayoría de los equipos, contesta preguntas y no elige carta. Tampoco debería votar la gerente que se ha sentado a mirar, por buena intención que tenga.

Un ejemplo: 3 contra 13 en una web municipal de cita previa

Un equipo mantiene la web donde los vecinos de un municipio reservan cita para hacer trámites: pedir un certificado, renovar una licencia, registrar una mascota. La historia de hoy dice: «Como vecina, quiero cancelar mi cita desde el enlace del correo de confirmación, sin tener que llamar por teléfono».

Las preguntas del equipo son pocas. ¿Hace falta pedir algún dato para cancelar? No, basta con el enlace. ¿Hay que avisar a la oficina? Sí, el hueco tiene que quedar libre para otra persona.

Votan seis personas: 3, 5, 3, 13, 5, 3.

Marta, que puso un 3, lo ve sencillo: «El correo ya lo mandamos nosotros. Añadimos un enlace firmado, una pantalla de confirmación y un endpoint que marque la cita como cancelada».

Andrés, el del 13, conoce otra parte del sistema: «La cita no vive en nuestra base de datos. La reservamos contra la agenda del municipio, que es un servicio SOAP de hace quince años sin operación de cancelar. Hoy las cancelaciones las hace a mano un funcionario desde su aplicación. Para liberar el hueco habría que pedir al proveedor que publique esa operación, y su entorno de pruebas se cae cada dos por tres».

El resto no sabía nada de la agenda. La product owner confirma que liberar el hueco es justo lo que le interesa al municipio, porque hay listas de espera de semanas.

Segunda votación: 13, 8, 13, 13, 20, 13.

Ahora la conversación es otra. El equipo decide dividir la historia: primero, que el enlace genere una solicitud de cancelación que el funcionario procesa desde su pantalla de siempre; después, la integración automática con la agenda, cuando el proveedor responda. La primera parte sale en la siguiente votación como un 3 y la segunda se queda con un «?» hasta tener noticias del proveedor. Si Marta hubiera dicho «esto es un 3» antes de votar, la historia habría entrado entera en el sprint y el problema de la agenda habría aparecido a mitad, con el compromiso ya hecho.

Trampas habituales

Soltar una cifra antes de tiempo

Un «esto son dos días, ¿no?» antes de la votación ya ha fijado el ancla. Pasa también con comentarios sin número, como el del product owner que avisa de que «es un cambio pequeñito». En una mesa física las cartas se sostienen boca abajo. En una herramienta online, los valores tienen que quedar ocultos hasta el final, y lo mejor es que ni siquiera lleguen a las pantallas de los demás.

Votar mirando al que más sabe

Cuando en el equipo hay alguien con mucha antigüedad, los demás tienden a acercarse a su número. En la segunda ronda es aún más fácil, porque su carta ya está a la vista. Ayuda que hablen siempre los extremos, sean quienes sean, y que la persona que facilita no pida primero la opinión del veterano. En el ejemplo de la cita previa municipal, el que sabía lo importante era Andrés, y podría haberse quedado callado.

Estimar lo que todavía no se entiende

Si las preguntas se quedan sin respuesta, cualquier número que salga será una ficción con aspecto de dato. En ese momento alguien debería jugar «?» y la historia volver al refinamiento; qué hacer con esa carta se explica en las cartas especiales. Una semana de retraso en la estimación sale mucho más barata que descubrir un requisito a mitad de sprint.

Quedarse con la media

Imagina una ronda sobre «exportar el historial de movimientos a Excel» que termina con 1, 2, 2 y 8. La media sale en 3,25 y es muy fácil anotar un 3 para no alargar la reunión. Ese número no describe lo que piensa nadie: tres personas creen que es trivial y una ve algo que las demás no, quizá que el historial de algunos clientes tiene cientos de miles de filas. La carta que se aleja pide una explicación antes que un promedio.

Planning poker a distancia

Con el equipo repartido entre varias ciudades, las cartas de cartón no sirven, y escribir el número en el chat de la llamada tampoco: el primero que escribe condiciona al resto. Hace falta un espacio común en el que cada uno vote a solas y las cartas se destapen juntas.

Una sesión remota suele ir así: quien facilita abre una sala y comparte el enlace en la videollamada, la historia se proyecta en pantalla para que todos lean lo mismo y cada persona vota desde su navegador. La sala muestra quién ya ha votado, sin enseñar qué. Cuando están todos, se revelan las cartas y se habla en la llamada. Si hay que repetir, se empieza una ronda nueva y las cartas anteriores desaparecen. SprintPoker funciona así, sin registro; el detalle está en la página sobre el proyecto.

Dos consejos para estas sesiones. Que quien facilita lea en voz alta el resultado de cada ronda, porque no todo el mundo tiene la sala a la vista mientras habla. Y que no pasen de una hora: por videollamada el cansancio llega antes, y a partir de cierto momento se nota en que ya nadie pregunta nada.

Si tu equipo trabaja con Scrum

La técnica no pertenece a ningún marco, pero la mayoría de quienes la usan trabajan con Scrum. Cuándo conviene estimar dentro del sprint y qué papel tiene el Scrum Master durante la votación se cuenta en la página de scrum poker.