Refinamiento del backlog: la reunión Scrum para un sprint más eficaz
No, el refinamiento del backlog no es otra reunión inútil impuesta por el marco Scrum... todo lo contrario.
Puede que no figure oficialmente como una ceremonia en la guía Scrum, pero se está convirtiendo cada vez más en una reunión importante para los equipos ágiles, ayudándoles a abordar la planificación y el progreso del siguiente sprint con mayor serenidad.
¿Qué es el backlog de refinamiento y cómo funciona? También le daremos algunos consejos para un refinamiento eficaz del backlog.
¿Qué es el refinamiento del backlog?
Definición
Para comprender plenamente el refinamiento del backlog, primero debemos tener claro el concepto de backlog.
El backlog es una lista de requisitos de negocio para un producto o proyecto, traducido en historias de usuario que describen la necesidad exacta del usuario. Lo compila y gestiona el Product Owner, y todo el equipo lo consulta durante la planificación del sprint para seleccionar las historias y funcionalidades que se comprometen a desarrollar durante el sprint.
El refinamiento delbacklog, o backlog grooming, es la acción de refinar el backlog en una reunión específica durante el sprint.
En términos prácticos, el refinamiento del backlog implica :
- Aclarar la comprensión de las historias de usuario,
- Estimar (o reestimar) el esfuerzo necesario para completarlas,
- Determinar el valor funcional de cada historia de usuario para facilitar la priorización,
- eliminar historias de usuario (si es necesario),
- añadir US (si es necesario).
🇫🇷 La traducción francesa de backlog refinement es affinage du backlog.
Refinamiento del backlog frente a la planificación de sprints
¿Cuál es la diferencia entre la reunión de refinamiento del backlog y la planificación del sprint?
La planificación del sprint tiene lugar el primer día del sprint y su objetivo es definir el objetivo del sprint y seleccionar las historias de usuario que el equipo se compromete a entregar al final. Puede durar unas 2 horas por semana de sprint.
El refinamiento del backlog es una reunión intermedia y complementaria a la planificación del sprint. Puede haber varias durante el sprint, y su propósito es preparar el terreno para la planificación del sprint, que debería ser más eficaz.
Participantes
¿Quién debe asistir a esta reunión? Deben asistir todos los miembros del equipo Scrum:
- el Producto Owner,
- el Scrum Master
- el equipo de desarrollo,
- cualquier otra persona que pueda ayudar.
👉 El Product Owner es el responsable de preparar, organizar y dirigir la reunión de refinamiento del backlog.
Objetivos
El uso regular del backlog de refinamiento tiene una serie de ventajas:
- Este trabajo preparatorio aporta tranquilidad a la hora de planificar y ejecutar el siguiente sprint,
- afina la comprensión de los requisitos
- prepara la estimación de las Historias de Usuario
- permite hacer balance a mitad del sprint
- puede acortar la duración de la planificación de la reunión del sprint.
Duración y frecuencia
Depende del equipo, pero al menos una reunión de refinamiento del backlog de una hora por sprint.
Sin embargo, con vistas a una agilidad continua, es aconsejable celebrar varias, aunque ello suponga acortar la duración. Esto permite al Product-Owner anticiparse y tener tiempo para reelaborar su US antes del final del sprint.
Secuencia del backlog de refinamiento
1. Presentación y comprensión de las historias de usuario
Como recordatorio, es el Propietario del Producto el responsable de traducir una petición o necesidad del usuario en una Historia de Usuario, de la forma más detallada y clara posible.
Por lo tanto, presentará al resto del equipo las Historias de Usuario que haya completado, o al menos las que ya estén bastante avanzadas.
El objetivo es garantizar que los miembros del equipo de desarrollo comprendan perfectamente el requisito, y que puedan plantear preguntas y debatir estas SDU. A continuación, el Propietario del Producto puede modificarlas o completarlas en función de las preguntas y los debates que hayan tenido lugar.
A continuación, el equipo puede validar la Historia de Usuario y pasar a estimarla.
👉 Si resulta que el equipo de desarrollo no entiende la petición, el Dueño de Producto tendrá que dedicar tiempo a reelaborar y aclarar sus NUS para volver a presentarlas en la siguiente sesión.
2. Afinar la estimación
El siguiente paso lógico después de validar los requisitos es que los desarrolladores los estimen.
Cada equipo tiene sus propios métodos y herramientas para estimarlos, pero en la práctica se tiende a estimar una US en puntos de esfuerzo más que en tiempo.
Los métodos más utilizados son :
- póquer de planificación
- el tamaño camiseta,
- el sistema de cubos.
Tú decides qué método se adapta mejor a tu equipo y a tus proyectos. Si resulta que una historia de usuario se vuelve complicada de estimar, lo mejor es subdividirla en diferentes US más pequeños para ver las cosas más claras.
💡 Es bueno saberlo: estimamos (o reestimamos) las Historias de Usuario para el siguiente sprint, o posiblemente para el siguiente, pero evitamos estimar con más antelación.
3. Priorización de los elementos del backlog
Conocer la estimación de una historia de usuario permitirá al equipo empezar a priorizar.
Sin embargo, pueden tenerse en cuenta otros criterios de priorización, en particular el valor funcional, que es esencial. Por eso es ingenioso determinar niveles de prioridad en función de la relación valor/esfuerzo:
- prioridad 1 (P1): alto valor empresarial y fácil de desarrollar,
- prioridad 2 (P2): alto valor empresarial y difícil de desarrollar,
- prioridad 3 (P3): valor empresarial bajo y fácil de desarrollar,
- prioridad 4 (P4): bajo valor comercial y difícil de desarrollar.
Por tanto, el equipo asigna órdenes de prioridad a los EE.UU., teniendo en cuenta que el objetivo principal es ofrecer el máximo valor lo antes posible.
💡 Bueno saber: la priorización se puede hacer sobre todo el backlog aunque los US no estén todos completos porque estamos en una visión más macro.
Consejos finales para un backlog de refinamiento eficaz
- Consejo nº 1: Como Product Owner, prepare meticulosamente la presentación de las Release Units explicando al equipo su forma de pensar, lo que cree que puede aportar, etc. Cuanto más entusiasta y claro sea, más probable será que el equipo compre su visión del producto y valide las Release Units. Cuanto más entusiasta y claro sea, más probabilidades tendrá de que el equipo asuma su visión del producto y valide las US.
- Consejo 2: Acepte preguntas, comentarios y opiniones negativas. Seguro que encuentra algo constructivo que añadir a su forma de pensar y, por tanto, a su EE.
- Consejo n.º 3: No espere hasta el último momento y hasta que haya terminado todos sus EE.UU. para crear el backlog de refinamiento. Es mejor presentar las historias terminadas con regularidad, durante los backlogs de refinamiento rápido, para poder anticipar si es necesario trabajar en ellas, ya que de lo contrario se podría poner en peligro el siguiente sprint. Evita el efecto túnel.
¿Y usted? ¿Tienes algún consejo para un Product Owner que se embarca en la aventura del refinamiento del Backlog?
Artículo traducido del francés