Agenda de la reunión de refinamiento del backlog: una estructura de 60 minutos y la regla de lo que se queda fuera

La mayoría de las reuniones de refinamiento del backlog fracasan porque el alcance se desborda. Lo que empieza como una revisión de 45 minutos de los detalles de los tickets se convierte en una discusión de una hora sobre arquitectura, estimaciones de historias que nadie ha escrito todavía y otra ronda del debate sobre el roadmap que todo el mundo daba por cerrado el trimestre pasado. Al final, el Product Owner tiene una página de notas garabateadas y nada está listo para el siguiente sprint.

La solución es sencilla: una estructura fija de 60 minutos, criterios de entrada que cada elemento debe cumplir antes de recibir tiempo de discusión y una regla, dicha en voz alta al principio, sobre lo que la reunión no va a tratar. Este artículo presenta esa agenda. Para la definición general del refinamiento y su lugar dentro de Scrum, lee la guía de refinamiento del backlog y la página del método Backlog Refinement. No voy a repetirlas aquí.

Por qué el refinamiento necesita un tiempo fijo

El refinamiento es una de las pocas actividades de Scrum sin un formato prescrito. La Scrum Guide lo describe como una actividad continua y no como un evento, así que cada equipo inventa su propia versión. En la práctica, un formato inventado sin estructura acaba en manos de quien más alto habla. Normalmente es la persona ingeniera más sénior o el Product Owner, y quienes desarrollan con menos voz, que son quienes construirán la cosa, dejan de aportar más o menos a los quince minutos.

Antes existía una referencia: la edición de 2017 de la Scrum Guide decía que el refinamiento «no suele consumir más del 10% de la capacidad del Development Team». La edición actual eliminó la cifra, pero quienes imparten formación de Scrum todavía la citan. Trata ese 10% como un techo. La mayoría de los equipos consiguen lo que necesitan con una sesión de 60 minutos a la semana, más la preparación del PO y algunas aclaraciones asíncronas en los comentarios de los tickets. Eso queda muy por debajo del techo y deja tiempo a quienes desarrollan para construir.

El refinamiento sin límites fracasa de una forma predecible. Los mismos tres elementos absorben casi toda la discusión, semana tras semana, mientras una docena de historias más nunca se revisan antes de la sprint planning. Entonces la planificación se convierte en refinamiento, y todo lo que viene después se retrasa.

Backlog grooming vs. refinamiento

«Grooming» era el término informal en los inicios de la práctica de Scrum para poner orden en el backlog: reordenar, eliminar elementos obsoletos, una limpieza ligera. «Refinement» (refinamiento) pasó a ser el término oficial cuando el sector reconoció este trabajo como una actividad propia, y organizaciones como Scrum.org retiraron «grooming» en parte por sus connotaciones negativas ajenas al tema (el Scrum Glossary usa ahora refinamiento en todo momento). Hoy la mayoría de los equipos usan las dos palabras indistintamente, y yo no corrijo a nadie que diga grooming. Aun así, merece la pena mantener la diferencia funcional. Grooming sugiere un mantenimiento pasivo que una sola persona puede hacer sola. El refinamiento es la preparación activa y colaborativa de elementos concretos por parte de quienes los van a construir, y por eso esta agenda lo trata como una sesión de trabajo con criterios de entrada.

En qué se diferencia el refinamiento de la sprint planning

El refinamiento es preparatorio y continuo. Ocurre a mitad del sprint, Scrum no le impone ninguna cadencia y su resultado son elementos del backlog más claros, más pequeños y estimados a grandes rasgos. La sprint planning es un evento formal de Scrum, con tiempo limitado, que se celebra una vez al inicio de cada sprint, y su resultado es un Sprint Goal y un Sprint Backlog.

Las dos también hacen preguntas distintas. El refinamiento pregunta: ¿se entiende este elemento lo bastante bien como para estimarlo y, más adelante, planificarlo? La sprint planning pregunta: ¿cuáles de estos elementos ya entendidos incorporamos y cómo los vamos a entregar?

Confundir ambas es la razón más común por la que veo que la sprint planning se pasa de su tiempo. Un equipo entra en una sesión de planificación de dos horas con historias sin refinar y dedica los primeros 30 minutos a dividirlas y a discutir los criterios de aceptación. Los equipos que se saltan el refinamiento descubren sus incógnitas en directo, en la planificación, donde resultan más caras.

Lo que el Product Owner prepara de antemano

Una sesión de refinamiento es tan buena como la preparación del PO. Cuando el PO llega sin preparar y recorre Jira buscando «algo de lo que podamos hablar», los primeros diez minutos se pierden y el resto de la hora no tiene forma. Pido a los PO lo siguiente al menos 24 horas antes de la sesión:

• Una lista ordenada de elementos candidatos, normalmente lo correspondiente a uno o dos sprints, donde lo primero de la lista es lo que el equipo verá primero.
• El contexto conocido adjunto a cada elemento: maquetas, enlaces a tickets relacionados, dependencias de otros equipos, citas de clientes.
• Cada elemento etiquetado como «listo para refinar» o «necesita descubrimiento aparte».
• Las preguntas abiertas que requieren la opinión de stakeholders, señaladas y con una nota sobre quién se encarga de conseguir la respuesta.

Lo que más importa es el etiquetado. Los elementos que no tienen ni siquiera un enunciado básico del problema deben filtrarse, porque necesitan una conversación de descubrimiento, y el refinamiento no es el espacio para descubrir. Cuando un PO llega con los elementos ya separados en esos dos grupos, me salto el segundo por completo. Nadie discute, porque el PO tomó la decisión antes de la reunión.

Criterios de entrada para cada elemento

Los criterios de entrada son una lista de comprobación breve que un elemento debe superar antes de ganarse tiempo de discusión. Muchos equipos la llaman una Definition of Ready ligera. El conjunto con el que empiezo con los equipos es este:

1. El elemento tiene una historia de usuario o un enunciado del problema claro en una sola frase.
2. Los criterios de aceptación están redactados, aunque estén incompletos.
3. No hay ninguna dependencia que bloquee por una cuestión de arquitectura sin decidir.
4. Es lo bastante pequeño como para caber en un sprint, o está marcado de forma explícita para dividirlo.

Una lista de comprobación permite a quien facilita decir «esto no cumple los criterios, siguiente» sin que suene a un juicio personal. Los juicios que se hacen sobre la marcha son el punto en el que el refinamiento deriva hacia el debate.

Quienes desarrollan tienen que escribir la lista contigo. Si el PO o el Scrum Master la imponen, el equipo la trata como burocracia y discute con ella a mitad de sesión. Quienes desarrollan son quienes tienen que responder «¿entiendo esto lo bastante bien como para estimarlo?», así que deberían escribir los criterios que lo definen. Dedícale un espacio de 20 minutos en una retrospectiva y revísala cada pocos meses.

La agenda de 60 minutos de la reunión de refinamiento del backlog

Esta es la agenda de la reunión de refinamiento del backlog que uso, en cinco bloques, cada uno con su propio temporizador.

• Minutos 0-5: Enuncia el propósito («dejar listos los siguientes elementos»), repite la regla de lo que queda fuera y confirma con el PO la cola de elementos ordenada de antemano. Si el PO quiere reordenar, se hace aquí, en menos de un minuto.
• Minutos 5-15: Revisa los dos o tres primeros elementos frente a los criterios de entrada. Los que no los cumplen vuelven al PO con una nota sobre lo que falta. Los que sí los cumplen pasan al siguiente bloque.
• Minutos 15-45: Discusión y estimación, de elemento en elemento, con un límite estricto de 8 a 10 minutos por elemento. El PO explica el problema, quienes desarrollan hacen preguntas y el equipo estima.
• Minutos 45-55: Divide cualquier elemento que haya resultado demasiado grande y afina la redacción de los criterios de aceptación de los elementos que ya están listos.
• Minutos 55-60: Resume las decisiones, revisa el parking lot, asigna responsables a los temas aparcados y confirma la fecha de la siguiente sesión.

Eso te da tres o cuatro elementos por sesión. A los equipos acostumbrados a «cubrir» quince tickets en una hora esto les parece lento al principio, pero tres elementos que de verdad están listos valen más que quince aprobados con un gesto de cabeza que volverán a salir en la planificación.

Cronometrar cada bloque y el temporizador por elemento

Poner un límite de tiempo a toda la reunión no basta. Los grupos alargan la discusión hasta llenar todo el tiempo disponible, y por eso los límites de tiempo se ponen a cada actividad. Pon un temporizador visible en cada bloque y en cada elemento. Cuando suena la alarma de los 8 minutos en una historia que sigue en disputa, digo «aparquemos esto y lo vemos aparte», y paso a lo siguiente. Ese único hábito salva más sesiones de refinamiento que cualquier otra cosa que conozca.

Para la estimación en sí, usa lo que tu equipo ya considere fiable. Planning Poker funciona; también el T-shirt sizing ágil si tu equipo prefiere categorías relativas a números. Elige una opción y no vuelvas a abrir cada semana la elección de la escala.

Construyo esta agenda una sola vez como plantilla reutilizable en Workshop Weaver, con los cinco bloques y sus duraciones fijas, para que quien facilita no tenga que reconstruir la estructura de memoria cada semana. Una agenda publicada también marca expectativas; como defendí en Tu agenda es una promesa, los bloques de tiempo son un compromiso con las personas que están en la sala.

El parking lot

Mantén un parking lot visible en el documento compartido o en la pizarra. Las tangentes del bloque de discusión van ahí con el nombre de quien las planteó. En los últimos cinco minutos, cada tema aparcado recibe una persona responsable y un siguiente paso. Sin responsables, el equipo aprende enseguida que «aparcarlo» significa «ignorarlo».

Lo que se queda fuera del refinamiento

La regla que leo en voz alta al principio de cada sesión: el refinamiento se detiene en «¿entendemos el problema y, más o menos, qué tamaño tiene?». Todo lo que va más allá de esa línea se trata en otro sitio. Hay tres categorías que la cruzan con más frecuencia.

Diseño de la solución

Cómo se va a construir la parte de ingeniería corresponde a un spike técnico o a una conversación de diseño aparte. Resolver la solución completa en el refinamiento se convierte en un debate al que solo dos o tres personas de la sala pueden aportar, mientras el resto mira el correo. Cuando alguien del equipo de desarrollo dice «bueno, esto lo podríamos construir de tres formas distintas», mi respuesta es: «Bien. Convirtámoslo en un spike y trae una recomendación». El elemento se estima como un spike o vuelve a la cola hasta que el spike esté terminado.

Estimaciones sin historia

Estimar un elemento que no tiene historia ni criterios de aceptación está fuera de los límites. El número no tiene base, y las estimaciones provisionales tienen la costumbre de volver al equipo meses después citadas como compromisos. Si alguien pregunta «¿no podemos ponerle un número aproximado?», la respuesta es devolverlo a los criterios de entrada.

Debates sobre el roadmap y las prioridades

Qué construir el próximo trimestre, si la estrategia tiene que cambiar, si esta funcionalidad importa siquiera: son conversaciones del liderazgo y del PO que tienen lugar fuera del refinamiento. La sesión acepta el orden de prioridad que el PO trajo a la sala. Si alguien del equipo de desarrollo cree que el orden es incorrecto, es una preocupación legítima, y va al parking lot con el PO como responsable en lugar de discutirse durante 20 minutos mientras la cola espera.

Hábitos de facilitación que sostienen la agenda

Designa a una persona facilitadora que no represente también las prioridades del PO ni las opiniones técnicas de quienes desarrollan. A menudo es el Scrum Master, pero una persona del equipo de desarrollo que rote funciona si el Scrum Master está demasiado cerca del contenido. Alguien que está discutiendo sobre el alcance no puede imponer con credibilidad un límite de tiempo a las discusiones sobre el alcance.

Repite la agenda y la regla de lo que queda fuera al principio de cada sesión, también en la cuadragésima. Parece repetitivo, pero da a quien facilita el permiso social para interrumpir en el minuto 22 sin parecer arbitrario, porque el grupo aceptó la regla veinte minutos antes.

Proyecta la agenda o mantenla abierta en una pestaña compartida en las sesiones remotas. Los equipos que hacen el refinamiento de memoria tienen muchos más momentos de «espera, ¿qué estamos haciendo ahora?» que los equipos que pueden ver el bloque actual y el temporizador. Mi guía anterior sobre cómo facilitar una sesión de refinamiento del backlog eficaz trata la configuración remota con más detalle.

Termina con un resumen por escrito: qué elementos están ahora listos, cuáles se dividieron y en qué, cuáles se devolvieron y por qué, y qué ha quedado aparcado y con quién. El PO actualiza el backlog a partir de ese resumen en menos de una hora, mientras las decisiones siguen frescas.

Trata la agenda como una disciplina y aplícala sin cambios durante tres sprints

La estructura de 60 minutos y la regla de lo que queda fuera protegen la atención del equipo para lo único para lo que sirve el refinamiento: dejar listos los siguientes elementos. Los límites de tiempo te parecerán ajustados en la primera sesión, y alguien pedirá más tiempo para un elemento que lo merece. Apárcalo de todos modos y mantén la estructura.

Antes de tu próxima sesión, siéntate con el equipo y escribe o actualiza la Definition of Ready del equipo, y luego usa la guía de refinamiento del backlog para adaptar los criterios de entrada a tu contexto. Después, aplica esta agenda exactamente tal como está escrita durante tres sprints. Registra cuántos elementos salen listos de cada sesión y cuánto de la sprint planning se dedica a refinamiento improvisado. Solo entonces ajusta los límites de tiempo, y cambia un bloque cada vez para poder saber qué marcó la diferencia.