El refinamiento Scrum pertenece a esa parte de la guía más abierta y que permite más libertad de decisión, al no ser un elemento básico de Scrum. En vez de entender bien su función dentro del marco, en las empresas tratamos de convertirlo en reuniones fijas que debemos atender. Esto ocurre por la necesidad de muchas empresas, sobre todo las grandes, de querer homogeneizar el método de trabajo. Sin embargo, el refinamiento no es una “reunión” como le puede pasar al resto de eventos, tiene una función de acompañamiento y evolución del Product Backlog. ¡Lo analizamos!
Refinamiento Scrum como pre-Planning
Hace mucho tiempo, acompañaba a un equipo Scrum compuesto por muchas personas. Este equipo estaba desarrollando un backoffice de un gran retail, para sustituir al actual, un producto que llevaría muchos meses de trabajo. Las primeras planificaciones eran infernales: requisitos muy cambiantes, tecnología antigua sin documentar, procesos mal definidos… Hacer la Sprint Planning costaba mucho tiempo. A pesar de que el equipo tenía Sprints de cuatro semanas, muchas veces necesitaban más de día y medio para finalizar la Sprint Planning, lo que sabíamos que era demasiado.
Un día, el Scrum Master del equipo, me dijo que habían conseguido solucionarlo y que la Sprint Planning actual apenas duraban dos horas. Le pregunté intrigado qué solución habían implantado. Me contó que, ahora, hacían refinamientos más largos con todo el equipo, estiman todas los items y lOs dividían en tareas, de manera que la Sprint Planning solo era un recordatorio. ¡Habían convertido el refinamiento Scrum en una pre-Planning!
Ahora gastan más tiempo en hacer lo mismo pero con menos foco. Mientras estaban “sprintando”, tenían que parar para pensar en el Sprint siguiente, sin haber terminado de inspeccionar el resultado de su Sprint actual.
¿Para qué se usa el refinamiento Scrum?
Muchos equipos Scrum piensan que el refinamiento sirve para preparar el siguiente Sprint y, por tanto, es una reunión en la que tenemos que refinar.
El refinamiento Scrum consiste en el acto de actualizar el Product Backlog de manera colaborativa entre el Development Team y el Product Owner. Tiene varios objetivos, una parte es dejar items “ready” para el siguiente Sprint. Esto es cierto, pero cuidado, no se hace una división por tareas (eso es trabajo del Sprint Planning).
La función principal del refinamiento Scrum es que el Product Owner pueda tomar decisiones sobre el producto para maximizar valor. Para poder tomar esas decisiones, necesitan información del propio equipo, ¿este item tiene dependencias? ¿es difícil? ¿hay incertidumbre? De esta manera, todo el Scrum Team entiende los próximos retos que van a venir y nos preparamos para ellos.
Por tanto, podemos darle forma de reunión, pero un refinamiento Scrum potente es aquel que se hace de manera continua, para generar una entrega continua. Los equipos que son capaces de hacer entrega continua (incluso de manera diaria), deberían pensar en que el refinamiento fuera de manera continua.
¿Y los Stakeholders?
En el refinamiento Scrum no participan los Stakeholders, ya que es un ejercicio entre Product Owner y Development Team. ¿Cómo llamamos al acto de hablar con los users, customers o managers para entender sus necesidades y plasmarlas en el Product Backlog? En Scrum, la toma de requisitos y necesidades apenas está descrita, dejando por tanto mucha libertad. Cómo el Product Owner y el resto del Scrum team descubrir el trabajo qué van a realizar queda dentro de la gestión de Producto que ellos hagan.
Este matiz es importante, si pensamos que el refinamiento Scrum es para Stakeholders y Product Owner, podemos cometer el fallo de no trabajar el Product Backlog con el Development Team. Esto a su vez, provoca que los items no estén “ready” y generamos Sprint Planning muy largas y pesadas, además de que podemos equivocarnos al no construir el producto correcto.
Cómo hacer un Refinamiento Scrum continuo
Hay una alternativa más interesante que aplican algunos equipos Scrum. Durante la Sprint Planning, podemos dedicar algo de tiempo a decidir los siguientes elementos que vamos a refinar durante el Sprint. Los miembros del equipo pueden seleccionar que items van a refinar y hacerlo de manera individual con el Product Owner. Después, en la siguiente Sprint Planning, el miembro del equipo le explica al resto en qué consiste ese Item (así el Product Owner se asegura que el conocimiento está dentro del equipo).
Otra alternativa es dedicar 15 minutos diarios para refinar. De esta manera, cada día disponemos de una ventana donde inspeccionar nuestro Product Backlog y adaptarnos. Es mejor refinar poco a poco que esperar a una reunión larga para hacerlo todo, así ganamos en continuidad y flujo.
Tablero de Refinamiento
Una manera de gestionar el Refinamiento Scrum es tener un tablero dedicado a ello. Este tablero suele contener los items del Product Backlogs de los próximos 3-4 Sprints y el estado de los mismos: ready o no-ready.
Esta técnica me la enseñó Alberto Serrano, y permite ir trabajando el futuro de nuestro producto, lo cual es útil para resolver dependencias, aclarar conceptos, gestionar expectativas entre otros. Aquí os dejo un ejemplo de un equipo con el que definimos un proceso de refinamiento que consiste en varios pasos. Previa al Refinamiento Scrum, teníamos diferentes partes en las que nos sentábamos con negocio o un experto evaluaba la viabilidad funcional de lo que nos habían pedido. Así, el Development Team solo tenía que refinar cuando estuviera claro el alcance.
El Refinamiento Scrum no se debe convertir en una “fase de análisis”, se trata de generar continuidad desde la entrega hasta la capacidad de aprender de nuestro negocio para decidir qué vamos a hacer. Y tú, ¿cómo haces el Refinamiento?
Gracias, me aclaraste unas dudas.
Detesto tener refinamientos repartidos en 3 días, quita agilidad y corta el trabajo que se está haciendo en el sprint