1. Refinamiento del Product Backlog en Scrum & Agile: concepto

El refinamiento del Product Backlog es el ejercicio de añadir detalles a sus elementos, de desmenuzarlos y con frecuencia dividirlos en otros más pequeños y concretos. Este acto te revisión suele implicar añadir descripciones, criterios de aceptación, estimaciones, actualizar la ordenación de los elementos, etc.

En Scrum y Agile, el refinamiento se entiende como una actividad, no necesariamente como una reunión especifica. Siempre que hablamos sobre el producto y anotamos los detalles de la conversación en el Backlog, estaremos haciendo refinamiento. Podemos hacer refinamiento en sesiones específicas, o durante Sprint Planning, durante o después del Daily Scrum, de manera informal entre miembros del Equipo, etc.

2. ¿Por qué es importante el refinamiento?

El refinamiento del Product Backlog nos permite generar un entendimiento compartido en torno a sus elementos. Recordemos que el Product Owner es responsable no solo de crear y comunicar los elementos del Product Backlog, sino de hacer que estos sean transparentes, esto es, comprendidos por el resto del equipo Scrum. Sin un trabajo colaborativo de refinamiento será casi imposible generar este entendimiento común. En otras palabras, el refinamiento nos permite asegurarnos de que todos estamos hablando de lo mismo.

3. ¿Son obligatorias las sesiones de refinamiento?

En Scrum no hay un evento o reunión de refinamiento como tal. No es una prescripción dentro del framework.

Sin embargo, estas sesiones pueden ser un instrumento de enorme utilidad para el Product Owner a la hora de conversar con el Equipo y crear transparencia en torno al Product Backlog. El Scrum Master puede facilitar estas sesiones y ayudar a que el Equipo extraiga el máximo valor de las mismas.

La anterior Guía Scrum indicaba que el refinamiento no debía superar el 10% de la capacidad del Sprint. En 2020, esta mención fue eliminada de la Guía. Lo normal es que, al principio de una iniciativa de desarrollo, el tiempo dedicado a refinamiento sea algo mayor, y que, luego, con el paso de los Sprints, todo sea más fluido y el refinamiento requiera menos esfuerzo. Pero todo depende de las circunstancias del producto en cuestión.

4. ¿Quién debe participar en el refinamiento?

El Equipo Scrum es responsable de todas las actividades necesarias para crear un Incremento de valor al final de cada Sprint y, como hemos dicho, el Product Owner ha de procurar que el Product Backlog sea transparente.

Dicho esto, puede ser que todo el Equipo Scrum participe en el refinamiento, para fomentar la colaboración, en sesiones específicas para ello o no; o puede ser que tan solo algunos de los miembros lo hagan, a riesgo de que los otros no puedan aportar su punto de vista o de que no estén al tanto de funcionalidades relevantes, pero en beneficio de una mayor velocidad. En definitiva, no hay prescripción al respecto y cada Equipo debe encontrar la forma de colaborar que le resulte más efectiva para hacer refinamiento.

5. Cómo hacer una buena sesión de refinamiento

No hay un formato “de manual” para hacer refinamiento. Aquí solo me gustaría compartir algunas de las prácticas que mejor me han funcionado a lo largo de los años.

Que participen las personas adecuadas

Una de las pautas que mejor me han funcionado ha sido la de sesiones cortas con todo el Equipo, de 45min-1h, una vez a la semana. Estas sesiones puede que se complementen con otras más largas o working sessions, en grupos más reducidos, como parejas o tríos.

Cuando sea necesario, no dudes en invitar a stakeholders, clientes, usuarios o expertos que puedan traer contexto específico y resolver preguntas del Equipo. Esta es una forma de implicar a los Desarrolladores en tareas de product discovery (si bien es probable que el Product Owner o algunos desarrolladores participen más directamente en estas).

Los beneficios de invitar a stakeholders a las sesiones de refinamiento pueden ser:

▶ 1/ El stakeholder nos aporta conocimiento, feedback o perspectivas que nos faltaban.

▶ 2/ El equipo tiene la oportunidad de interactuar directamente con el stakeholder. De apreciar un mayor contexto sobre el producto, sin que el Product Owner / Manager tenga que hacer de “correveidile”.
▶ 3/ Es también una forma de involucrar a tus stakeholders, de hacerles partícipes del proceso de creación del producto. Y así generar más confianza.

No digo que siempre tengamos que invitar a stakeholders a los refinamientos. Pero es algo con lo que experimentar.

Énfasis en el porqué

Las sesiones de refinamiento son una ocasión perfecta para que Product Owner y Desarrolladores colaboren y lleguen acuerdos sobre las funcionalidades a abordar. El Product Owner puede compartir especificaciones, solicitar ideas, aclarar dudas, etc. Hay mucho contexto detrás de cada elemento del Product Backlog que el Product Owner puede compartir con el resto; el Product Owner puede ilustrar el Equipo sobre el porqué detrás de las cosas.

Llevar especificaciones “no finales”

Como Product Owner, casi siempre intento llevar al refinamiento especificaciones con cierto detalle, pero inacabadas y muy abiertas a modificaciones. Lo importante es que los Desarrolladores entiendan qué queremos hacer y por qué; a partir de ahí, puede haber varias soluciones posibles y, entre todos, colaborativamente, queremos encontrar la más sencilla. Plantear el refinamiento como una sesión en la que el Product Owner entrega las especificaciones a los Desarrolladores, de manera unilateral, no tendría ningún sentido.

Por supuesto, también puede ser que estas especificaciones iniciales hayan sido trabajadas por uno o varios Desarrolladores, por delegación del Product Owner.

Preparación previa

Circular los elementos del Product Backlog que se van a refinar en la sesión puede ayudar a que esta sea más efectiva, de manera que los participantes puedan leer cualquier documentación, si la hay, y preparar preguntas o comentarios con carácter previo.

Refinemos elementos de alta prioridad

Querremos centrarnos en refinar elementos que potencialmente serán seleccionados en el próximo Sprint o el siguiente, pero no mucho más allá. Lo contrario es arriesgarse a refinar elementos que quizás nunca sean implementados, malgastando nuestro tiempo. Se trata de refinar lo más just in time posible. También hay que tener en mente que podemos refinar un mismo elemento en múltiples ocasiones. Puede que inicialmente solo lo hagamos de forma genérica, y que sucesivamente lo hagamos de manera más concienzuda.

Divide y vencerás: ¿cuál es la funcionalidad mínima que necesitamos primero?

La actividad de refinamiento debe llevarnos a crear elementos del Product Backlog que sean lo suficientemente pequeños como para ser terminados en un Sprint (algunos Equipos utilizan la llamada Definición de ready). Por tanto, debemos poner el foco en determinar cuál es el producto mínimo viable (PMP) que necesitamos, y así descomponer el elemento del Product Backlog en otros de menor tamaño, que ordenaremos según prioridad. También puede ser que identifiquemos tareas concretas de implementación, puesto que los Desarrolladores querrán valorar aspectos técnicos de manera más precisa.

Para tener un cierto ritmo durante el Sprint, en la práctica, lo mejor será que podamos completar cada elemento del Product Backlog en un máximo de 2-3 días o menos. Para hacer el sizing existen diferentes técnicas; las que casi siempre utilizo son:

a) #Noestimates. Creamos elementos del Product Backlog que tengan un tamaño similar, “a ojo”, basándonos en nuestra experiencia, y acordamos cuántos elementos podemos seleccionar para el Sprint.

b) Estimación relativa mediante planning poker, que nos sirve como técnica de alineamiento del Equipo, para comprobar si efectivamente tenemos un entendimiento compartido sobre el elemento del Product Backlog y cómo lo vamos a implementar.

• El Equipo comenta el elemento, tras lo cual cada uno proporciona su propia estimación, según su conocimiento del elemento en comparación con otros. Si todos están de acuerdo con el tamaño, es probable que los Desarrolladores estén alineados.
• Si discrepan en el tamaño o si hay valores atípicos, esto suele revelar asunciones diferentes sobre el elemento del Product Backlog. Aquellos con estimaciones atípicas pueden explicar su razonamiento, para entonces hacer otra ronda de estimaciones e intentar alcanzar un consenso.
• Por cierto, solo los Desarrolladores hacen el sizing (y no el Product Owner ni el Scrum Master), puesto que son ellos quienes hacen el trabajo de creación del Incremento.