Lo que debes saber sobre el Product Backlog Refinement

Para que un Sprint pueda planificarse y el trabajo pueda comenzar en Scrum, el Product Backlog debe estar bien mantenido y lleno de Product Backlog Items adecuadamente preparados. Es lógico que el Backlog deba refinarse regularmente, pero ¿cómo funciona realmente?

En este artículo te mostraremos exactamente qué significa el Product Backlog Refinement, a qué debes prestar atención y por qué el refinamiento es tan importante.

¿Qué es el Product Backlog Grooming o Refinement en Scrum?

Hasta hace poco, el Product Backlog Refinement en Scrum se llamaba Backlog Grooming. El Backlog Refinement consiste en mantener y preparar el Product Backlog con sus elementos y epics para que el equipo Scrum pueda usarlo como base para el Sprint Planning.

Product Backlog Refinement significa, por tanto: los Product Backlog Items se elaboran, evalúan y priorizan de tal manera que el equipo de desarrollo pueda compilar su Sprint Backlog a partir de ellos. Un Product Backlog bien mantenido siempre debe contener al menos suficientes Product Backlog Items preparados como para poder planificar un Sprint completo.

El objetivo general del Backlog Grooming es asegurar que el equipo de desarrollo comprenda la visión de producto del Product Owner y las User Stories que ha creado, y así sea capaz de planificar el siguiente Sprint según los objetivos del Sprint.

Por cierto, si buscas el término Refinement en la Guía Scrum, descubrirás que no es uno de los eventos u ocurrencias oficiales de Scrum como el Sprint y el Daily Scrum. Más bien, el Product Backlog Refinement es una llamada actividad que tiene lugar como reunión. Además del Product Owner y el equipo de desarrollo, el Scrum Master y, especialmente en el caso de refinamientos estratégicos, los stakeholders participan en la reunión de refinamiento.

Así funciona la reunión de Backlog Refinement

Antes del Backlog Refinement propiamente dicho, viene la preparación:

• El Product Owner establece el objetivo del Sprint (Outcome).
• Según este objetivo del Sprint, el PO prioriza el Product Backlog y selecciona los Product Backlog Items (PBIs) más importantes o escribe nuevos.
• El equipo Scrum formula conjuntamente una Definition of Ready (DoR), que define qué características o qué nivel de detalle deben tener estos Product Backlog Items para que el equipo de desarrollo pueda incluirlos en un Sprint.

Ahora es el momento de realizar la reunión de Backlog Refinement:

• El Product Owner y el equipo de desarrollo discuten los objetivos del Sprint y los PBIs asociados. Es importante que el PO solo comunique el objetivo a alcanzar y no especifique cómo debe lograrse.
• El equipo de desarrollo aporta su input. Esto incluye, por un lado, sus propias ideas para la implementación, basadas en su conocimiento de la aplicación o producto, y por otro, comentarios sobre dependencias técnicas entre los PBIs, tras lo cual se reprioriza algún tema.
• Tan pronto como el equipo de desarrollo y el PO han alcanzado una comprensión común de un Product Backlog Item, el PO o un miembro del equipo documenta este PBI según la DoR formulada en el punto 3 y anota los criterios de aceptación, por ejemplo. Muchos equipos también realizan la estimación del esfuerzo en este punto; entonces lo llaman Estimation Poker en lugar de Planning Poker, ya que no tiene lugar en el Sprint Planning.

¿Por qué es necesario el Product Backlog Refinement (Grooming) para el éxito?

Un buen Product Owner se toma el refinamiento muy en serio. Sabe que un Backlog Grooming regular y serio sienta las bases para el curso del Sprint subsiguiente y, por tanto, para el éxito de un producto, porque:

• El Refinement asegura que el Product Backlog esté actualizado y pueda utilizarse como base para el próximo Sprint Planning.
• Este tipo de trabajo preliminar permite al equipo de desarrollo abordar los PBIs más importantes en una etapa temprana y hacer preguntas que de otro modo solo surgirían durante el Sprint Planning. Esto le da al PO la oportunidad de encontrar las respuestas a tiempo para la reunión de Planning.
• Las reuniones de Sprint Planning se acortan, porque ahora solo hay que discutir el "cómo" de la implementación, ya que el "qué" ha sido clarificado por el refinamiento. Además, los PBIs idealmente ya han sido estimados por el equipo y pueden seleccionarse según la velocity. Esto evita que no haya suficientes PBIs preparados disponibles en el Sprint Planning.
• Al trabajar juntos en los PBIs, el PO y el equipo de desarrollo desarrollan más rápidamente una comprensión común de la visión, los objetivos y las tareas. Todas las ideas del equipo de desarrollo para la implementación de un PBI se anotan en el Refinement.
• Se produce una enorme transferencia de conocimiento, ya que el PO da al equipo cada vez más contexto sobre clientes, modelo de negocio, etc. a través del Refinement.
• En el Sprint, el equipo puede concentrarse más en el trabajo real, porque las preguntas más importantes se clarificaron en el refinamiento.

¡Esto es lo que debes tener en cuenta durante el Product Backlog Refinement!

• Antes de poder priorizar u ordenar definitivamente los PBIs en el Product Backlog, debes tener una idea del alcance de los elementos individuales, porque esto determina los costes, que a su vez influyen en la prioridad. En Scrum, el alcance se estima en unidades de medida relativas como los Story Points.
• Scrum no especifica cuándo ni con qué frecuencia hay que hacer el Product Backlog Refinement. Nuestra recomendación es: 1 vez por semana, por ejemplo, a mitad del Sprint. Algunos equipos realizan Refinements diarios y más cortos, lo que depende principalmente de la disponibilidad del Product Owner.
• Al igual que con los eventos y otras actividades en Scrum, también se recomienda que los Product Backlog Refinements se realicen regularmente según un ritmo fijo para que se desarrolle una rutina.

Conclusión sobre el Product Backlog Refinement

Un Product Backlog Refinement regular y limpio es absolutamente esencial para un Sprint exitoso y, por tanto, para el éxito del producto. Si ya trabajas como Product Owner o te gustaría prepararte para este emocionante rol y practicar el Product Backlog Refinement, estaremos encantados de apoyarte con una formación de Product Owner adecuada.