¿Qué es el refinamiento de producto en Scrum?

¿Qué nos dice la guía Scrum sobre el refinamiento de producto?

“Product Backlog Refinement» es el acto de desglosar y definir los Product Backlog Items en elementos mas pequeños y precisos. Es una actividad continua para añadir detalles (como descripción a los PBIs), orden (o prioridad), talla (tamaño o estimación). Estos atributos pueden cambiar dependiendo del contexto del producto. Solo los developers pueden ofrecer una estimación de los PBIs. El Product Owner puede ayudarles a entender ciertos PBIs y buscar el mejor balance o equilibrio ”

De esta pequeña definición de este acto quedan muchas preguntas abiertas: ¿Con qué frecuencia debemos refinar?¿cómo se hace? ¿Quién asiste a esta sesión? ¿como facilitarla? ¿Cuántos ítems hay que refinar por sesión? Se intentará responder a todas estás preguntas.

¿Qué se hace en el refinamiento?

El refinamiento del Product Backlog  es el acto de desglosar y definir mejor los elementos del Product Backlog en elementos más pequeños y precisos. Se trata de una actividad continua para añadir detalles, como la descripción, el orden y el tamaño. Los atributos suelen variar según el ámbito de trabajo.

¿Y qué significa en realidad? Pues que el Scrum Team debe de reunirse varias veces por Sprint, donde se reúnen los developers, Product Owner e incluso algunos Stakeholders. Debe de ser una actividad continua para crear un flujo que permita generar PBIs (Product Backlog Items) Ready To Start. 

Muchos equipos suelen trabajar para asegurarse tener trabajo suficiente para dos Sprints vista, esto también depende de la duración de los sprints, ya que quizás para un Sprint de un mes, una previsión de 2 Sprints pueda parecer un mundo, pero ojo es una previsión e hipótesis que puede cambiar. Tener una previsión de 2 sprints vista puede ahorrarle muchos problemas a muchos equipos: vacaciones, enfermedades, contratiempos, gestiones con otros equipos, etc.

¿Pero qué sucede realmente en el refinamiento? Primero, los PBIs deben de llegar con un claro Qué y Para Qué para invertir tiempo en esta Feature/historia/etc.

Al final hay que verlo de la siguiente manera: ¿Qué necesita el usuario?¿Como aceptaría un usuario final esta feature? Si estás cosas no saben o no están claras, comenzaremos a discutir y debatir, mucho tiempo se invertirá en saber el Qué, Para Qué y el Cómo (no digo que esto debe de estar claro al 100% para todo el mundo, sino que hay cierto trabajo previo que hay que hacer…), mejor que cada uno se lleve deberes fuera de esta sesión: PO, que hable con los Stakeholders sobre el Qué y el Para Qué, los developers que vean opciones y soluciones posibles sin llegar a cerrar nada, a veces suelen crear un spike para investigar (esto es peligroso…  😜).

También es posible que haya dudas sobre otros sistemas en la organización, quizás deberían invitar a estas personas a este refinamiento. En resumen, si estamos más de 15 minutos discutiendo los temas de arriba y estamos sin dirección clara hacia donde ir o cómo continuar, pues debemos de plantearnos cómo estamos realizando nuestros refinamientos. 

Dividir PBIs

El refinamiento tiene un objetivo claro, tener elementos listos para abordarlos en los siguientes Sprints (Sprint +1, Sprint +2…), esto significa que deben de ser lo suficientemente pequeños como para poder entregarlos,  esto nos lleva a cumplir con el Definition Of  Done. Personalmente suelo recomendar que los PBIs no deban de ocupar (hipotéticamente hablando…) más de la mitad del Sprint (y esto es mucho tiempo). Esto nos lleva a la siguiente reflexión, Pero… es que nuestros PBIs son grandes… pues lo siento, hay que dividirlos.

La mayoría de los equipos se estancan aquí, porque dividir los PBIs no es una tarea fácil, requiere de creatividad, colaboración a veces de innovación, de ver más allá, de ver el bosque en lugar del árbol. ¿Y por dónde empezamos a dividir? La vedad que hay muchas técnicas para poder dividir los PBIs, pero antes recomendaría hacer un workshop para que el Scrum Team entienda el propósito y el para qué de dividir los Ítems y su importancia en la agilidad, para ello se puede utilizar la dinámica de Elephant Carpaccio de Alistair Cockburn & Henrik Kniberg

Y como técnicas de división hay varias otras que se pueden utilizar:

Estimar

Y por fin hemos llegado hasta el punto más conflictivo, estimar o no estimar, pues a ver, en Scrum se habla de estimar los PBIs pero no como hacerlo ni con qué medida, esto ya depende del contexto, necesidad y el Scrum Team. Hoy se verán algunas técnicas para poder estimar en equipos Scrum:

No hay que olvidar que el objetivo no es estimar, a no ser que el equipo venda estimaciones… quizás en ese caso… habría que prestarle mucha atención a las estimaciones… Estas últimas por defecto se deben de considerar como incorrectas, erróneas e inexactas…  

Criterios de aceptación

Uno de los elementos mas relevantes son los criterios de aceptación, no es algo nuevo, sino es un tema viejuno la verdad, no obstante es un tema muy olvidado y no hablamos de automatizar los criterios de aceptación utilizando BDD. Añadir los criterios de aceptación a los PBIs se podría hacer perfectamente en el Refinamiento de Producto, esto se debe de realizar con el Product Owner, los Developers y por que no algunos Stakeholders (¿usuarios?)

Los criterios de aceptación ahorrarían muchos problemas a nivel de entendimiento común, inicialmente entre el PO, Stakeholders y los Devs. Al tener los criterios de aceptación, sabremos si realmente cumplimos con las expectativas de los Stakeholders o no. Y si los podemos automatizar y introducirlos en el pipeline de CI/CD sería super interesante 

Facilitando una sesión de refinamiento en Scrum

Stephan Van Rooden nos deja un gráfico muy descriptivo sobre cómo abordar una sesión de refinamientos y ciertas preguntas a tener en cuenta: