Refinamiento del Product Backlog ¿Cuándo y Cómo?

Como ya describí en el artículo Resumen de Scrum Guide el refinamiento es el evento en el que se trabajan las Historias de Usuario para evaluar su descripción y estimación. Para revisar las Historias de Usuario deben estar todos los miembros del Equipo Scrum:

• Equipo de Desarrollo: serán quienes deben entender cada Historia de Usuario a fin de valorarla para darle una estimación. Serán ellos quienes determinen si una Historia de Usuario se entiende o no.
• Product Owner: será la persona que deba aclarar todas las dudas del Equipo de Desarrollo hasta que lo entiendan y quien redefina cada Historia de Usuario hasta que sea lo suficientemente pequeña como para poder estimarse y llevarse a cabo dentro de un Sprint.
• Scrum Master: como siempre será el facilitador de esta reunión. Para equipos poco maduros deberá estipular las partes y pautas de la reunión. En equipos más maduros no será necesaria la intervención del Scrum Master.

Las Historias de Usuario deberán refinarse tanto como así lo estime el Equipo de Desarrollo conjuntamente con el Product Owner. Y según la Scrum Guide el refinamiento no debe ocupar más del 10% del tiempo del Equipo de Desarrollo.

Inicialmente el Product Owner escribirá las Historias de Usuario en función de lo que los Stakeholders le cuente. Estas Historias de Usuario normalmente tendrán un nivel muy alto de especificación y por lo tanto necesiten redefinirse. A estas Historias de Usuario se las denomina EPIC (a un conjunto de EPIC's que definan un módulo o subsisten del producto se le llama Tema).

Con todo lo descrito anteriormente nos podemos hacer una vaga idea de lo que debe ser el evento del Refinamiento del Product Backlog. Sin embargo, al menos así me ha pasado a mi, surgen algunas dudas como: ¿Y cuando hacemos realmente el Refinamiento? ¿Hay técnicas para llevar a buen puerto este evento?. Y para contestar a estas dudas he creado este Post.

¿Cuándo debemos hacer el Refinamiento del Product Backlog?

De la Guía de Scrum saqué la conclusión de que el refinamiento del Product Backlog se debía hacer durante el Planning Sprint. Sabemos que el Planning Sprint no debe durar más de 8 horas para un Sprint de 4 semanas. También es cierto que el refinamiento no deber suponer más del 10% del esfuerzo del Equipo de Desarrollo.

En 4 semanas hay 160 horas, pongamos que productivas son el 80%, eso nos deja 128 horas. Si usamos, no el 10%, sino el 5% del tiempo del Sprint para refinar se podrían utilizar 6 horas y cuarto. Si agotamos el tiempo del refinamiento nos queda apenas una hora y tres cuartos para la planificación. Aquí algo no me cuadra :P.

Pero existe otra forma de hacer los cálculos. Si acotamos ese 10% del esfuerzo sólo a la reunión de Planificación nos quedaremos con un tiempo de 48 minutos para el refinamiento de HU, siendo generosos lo podemos dejar en 50 minutos. Por lo que he leído, un tiempo razonable para refinar una única HU es de 10/15 minutos. Personalmente creo que para acotar el refinamiento de cada HU a este tiempo se ha ser bastante ágil y tener las cosas muy claras y bien preparadas. Por lo tanto, con apenas 50 minutos y siendo muy ágiles (10 minutos por HU) apenas podremos revisar 5 para un Sprint de 4 semanas. Creo que algo tampoco va bien por aquí porque 5 HU con el tamaño adecuado no serán suficientes para ocupar a un equipo durante 4 semanas.

Buscando y buscando la respuesta a mi duda y con el objetivo de encontrar una solución a estos cálculos que no me satisfacían los mirase como los mirase me topé con un artículo muy interesante dónde se habla justo de este tema. El artículo está escrito por Erich Buhler en 2016 y se titula "Cómo hacer un buen refinamiento en Scrum".

La propuesta de Erich Buhler es la de hacer pequeñas reuniones durante la semana. Las reuniones deberán tener un tiempo máximo (time-box) de 45 minutos. Según la madurez del equipo y su agilidad para llevar a cabo esta reunión se podrán tener entre 2 y 3 reuniones a la semana. La propuesta me parece muy completa ya que tiene un tiempo definido y cerrado lo que fomenta la agilidad, además la propuesta es flexible en función de la madurez del equipo. Como siempre, cuando y dónde realizar la reunión deberá ser elegido por el equipo y en mi opinión dejarlo fijado en el Sprint Planning me parece la mejor opción.

Dos o tres reuniones de 45 minutos a la semana puede parecer mucho tiempo, pero sorprendentemente ni con 3 reuniones se supera el 10% definido en la Guía de Scrum. Pongamonos en el caso de tener unas 35 horas hábiles a la semana (40 horas de trabajo menos 15 minutos de Scrum Diario y 45 minutos de solución de dudas surgidas durante el Scrum Diario por parte del Equipo de Desarrollo). El 10% de 35 horas hacen 3,5 horas. 45 minutos 3 veces a la semana hacen un total de 135 minutos que son 2 horas y cuarto. Por lo tanto nos queda mucho margen para llegar al 10%.

Otra cosa positiva de la propuesta es que es válida con indiferencia del tamaño del Sprint. Dado que la propuesta habla de reuniones semanales da igual si el Sprint dura 1, 2, 3 o 4 semanas.

En estas reuniones de refinamiento no se deben tratar temas técnicos sino sólo de negocio y entendimiento de las Historias de Usuario. Después, en el día a día el Equipo de Desarrollo podrán hablar y discutir de los detalles técnicos que podrán llevar a una modificación de la estimación. A estas conversaciones posteriores Erich Buhler las denomina Refinamientos Esporádicos.

¿Cómo debemos hacer el Refinamiento del Product Backlog?

Como en todas las reuniones de Scrum existen algunas reglas que se deberán definir entre todo el Equipo de Scrum. En el caso del Refinamiento se deberán establecer, al menos, dos reglas:

• Definición de "Ready" para determinar cuando una HU está lista para entrar en un Sprint Backlog. Con esta definición se busca en primer lugar asegurar que el Equipo ha entendido cada HU y en segundo lugar que no se pueda meter a última hora en el Sprint Backlog una HU sin que esté preparada para ser ejecutada. En la página de Erich Buhler se hace una propuesta de definición de "Ready", a continuación muestro los elementos que me parecen más representativos:
• Ha pasado 2 refinamientos.
• Tiene una estimación.
• El equipo se siente cómodo y entiende que lo que está resolviendo es un problema para el cliente.
• Se entienden y el Equipo de Desarrollo está conforme con los criterios de aceptación. 
• Tiempo para tratar cada HU. Se propone un tiempo de 10/15 minutos a fin de no perdernos en discusiones y poder garantizar que se avanza en el reunión.

Una vez establecidas las reglas, generalmente en la primera reunión de refinamiento, se pueden comenzar estar reuniones. Las reuniones son preparadas entre el Product Owner y el Scrum Master. En el artículo se hace una propuesta muy interesante. Ellos deciden utilizar post-its para escribir las Historias de Usuario y pegarlas en la pared. De esta manera se tienen varias ventajas: el espacio es limitado por lo que el texto de las Historias de Usuario debe simplificarse, está a la vista de todos y se puede trabajar con ellos de una manera más interactiva.

Espero que haya servido para aclarar algunas dudas, a mi desde luego sí :D.

Un abrazo a tod@s