Scrum poker en un equipo Scrum
En muchos equipos Scrum, al planning poker se le llama simplemente scrum poker. La mecánica no cambia: cartas elegidas en secreto, revelación simultánea y conversación cuando los números no cuadran. Las reglas y un ejemplo completo están en la guía de planning poker. Aquí interesa otra cosa: en qué punto del sprint se estima, quién conduce la sesión y qué uso tienen después esos números, que casi siempre son puntos de historia.
Lo que la Guía de Scrum no dice
Quien abre la Guía de Scrum buscando instrucciones para estimar se lleva una sorpresa. La guía pide que los elementos del Product Backlog se refinen hasta que quepan en un sprint y deja en manos de los Developers, los que harán el trabajo, la decisión sobre su tamaño. No habla de puntos de historia, ni de cartas, ni de velocity, ni de Fibonacci.
Todo eso son prácticas que los equipos han ido adoptando a su alrededor. Los puntos y la velocity vienen en buena parte de Extreme Programming y se extendieron por los equipos Scrum a lo largo de los años 2000. Un equipo que estima en días ideales, en tallas de camiseta o que directamente no estima sigue cumpliendo la guía.
Esto tiene una consecuencia práctica. Si las sesiones de estimación se han vuelto un trámite que nadie aprovecha, el marco no obliga a mantenerlas tal cual. Se pueden acortar, cambiar de momento o eliminar, siempre que el equipo siga entendiendo el trabajo que le llega y planificando sprints que pueda cumplir.
¿En el refinamiento o en la Sprint Planning?
Hay dos momentos naturales para sacar las cartas, y la mayoría de los equipos acaba usando los dos con pesos distintos.
En el refinamiento del backlog
El refinamiento (hay quien todavía dice grooming) es el trabajo de ir aclarando y recortando las historias que vienen. Muchos equipos lo hacen en una o dos reuniones por sprint de no más de una hora. Es el mejor sitio para el scrum poker: las historias todavía tardarán un par de sprints en entrar, así que queda margen para resolver dudas con el product owner o con otros equipos, y si una historia resulta enorme se divide con calma.
Pongamos el equipo que desarrolla el alta de clientes en la app de un banco. En una sesión de refinamiento estima «validar la foto del documento de identidad antes de enviarla» y alguien juega «?»: nadie sabe si el proveedor de verificación acepta documentos de otros países. La duda se lleva a quien corresponde y la historia vuelve la semana siguiente, sin que nadie haya tenido que improvisar.
En la Sprint Planning
La Sprint Planning sirve para decidir qué entra en el sprint y cómo se va a hacer. Si las historias llegan ya estimadas, la conversación es rápida: se compara la suma con la velocity de los últimos sprints y se ajusta. Como mucho se vuelve a votar alguna historia en la que haya cambiado algo desde el refinamiento.
Cuando toda la estimación se deja para este momento, la reunión se alarga y se vuelve pesada. Hacia la sexta historia confusa del día, la gente vota lo que haga falta para salir de ahí. Si eso te resulta familiar, intenta mover la estimación al refinamiento durante un par de sprints y compara.
El Scrum Master mientras el equipo vota
Si el Scrum Master no desarrolla, no vota. Su trabajo durante la sesión consiste en cuidar el proceso sin protagonizarlo.
Antes de votar se asegura de que todo el mundo ha entendido la historia. Una pregunta abierta del tipo «¿a alguien le falta saber algo?» suele destapar la duda que alguien no se atrevía a plantear.
Mientras se vota, defiende el silencio. Si alguien suelta un número antes de tiempo, puede pedir que se repita la ronda o recordar la regla sin dramatizar. Después de dos o tres veces, el equipo se corrige solo.
Cuando se revelan las cartas, da la palabra a los extremos, por su nombre y siempre en el mismo orden. Cuando se hace siempre igual, a nadie le sorprende que le toque explicar su carta.
Y vigila el tiempo. Cinco o seis minutos por historia es una referencia razonable; si tras dos rondas no hay acuerdo, la historia se aparca y alguien se lleva la tarea de resolver la duda.
En una buena sesión, el Scrum Master apenas se oye: la mayor parte del tiempo hablan los desarrolladores, explicándose unos a otros por qué eligieron su carta.
Las cartas «?» y ☕
«?» indica que a la historia le falta información y ☕ que el equipo necesita parar un momento. Ninguna de las dos debería pasarse por alto; cómo tratarlas se explica en las cartas especiales.
Bugs, spikes y deuda técnica
No todo lo que entra en un sprint es una historia de usuario, y cada equipo decide si estima lo demás. Lo importante es decidirlo una vez y mantenerlo.
Bugs. Unos equipos los estiman como cualquier historia y cuentan para la velocity. Otros no les ponen puntos y asumen que la velocity refleja solo trabajo nuevo; así, un sprint lleno de incidencias se nota en la cifra, lo cual también es información útil.
Spikes. Una investigación acotada en el tiempo, como averiguar qué documentos admite el proveedor de verificación del ejemplo anterior. Como su límite ya está fijado (por ejemplo, un día y medio), muchos equipos no la puntúan y simplemente la restan de la capacidad del sprint.
Deuda técnica. Actualizar la librería de firma electrónica o sacar la lógica de comisiones de un procedimiento almacenado compite con las funcionalidades por el mismo sprint. Estimarlo en puntos hace que el product owner vea el coste y lo pueda priorizar, en lugar de que se esconda dentro de otras historias.
La relación con la velocity
La mayoría de los equipos estima en puntos para tener velocity, la suma de puntos terminados en cada sprint, y usarla al decidir cuánto trabajo cabe en el siguiente. El scrum poker ayuda a que esa cifra signifique algo, porque cada estimación la acuerda el equipo entero y la escala no se desvía como cuando estima una sola persona. Cómo se calcula y qué errores se cometen con ella está en Velocity: para qué sirven los puntos.
Cuándo puedes prescindir del scrum poker
Hay equipos que funcionan bien sin él.
- Si las historias se cortan siempre hasta que ocupan uno o dos días, basta con contar cuántas se terminan por sprint.
- En un equipo de dos o tres personas, una conversación corta puede ser suficiente, aunque votar a ciegas sigue protegiendo del efecto ancla.
- Los equipos que trabajan con Kanban o en flujo continuo suelen medir el tiempo de ciclo y no estiman elemento por elemento.
- Si nadie usa las estimaciones para planificar ni para hacer previsiones, generarlas es tiempo perdido.
En el otro extremo, si el equipo termina sprint tras sprint con trabajo a medias, o la planificación se parece más a una apuesta que a un cálculo, unos cuantos sprints de scrum poker constante suelen dejar claro dónde está el problema. Para la próxima sesión basta una sala online gratuita, sin registro para nadie.