Guía de Scrum | 40. Cuidado del Product Backlog

El cuidado del Product Backlog es una de las tareas principales de un Product Owner. El proceso de cuidado incluye formular, detallar y agregar nuevas User Stories al Product Backlog. Sin embargo, la tarea más importante del cuidado es asegurar que las entradas colocadas en el Backlog estén en el orden correcto, es decir, que sean priorizadas.

Cuidado del Product Backlog – tabla de contenido:

1. Introducción
2. Propósito del cuidado del Product Backlog
3. Errores en el mantenimiento del Product Backlog
4. Mantenimiento del Backlog vs. métricas utilizadas en Scrum
5. Resumen

Introducción

El Product Backlog es uno de los Artefactos de Scrum. Contiene una lista priorizada de trabajo necesario para crear un Producto. En otras palabras, es una lista de User Stories necesarias para alcanzar el Objetivo del Producto. Puedes encontrar una descripción detallada de lo que son las User Stories en este artículo. Y aquí están los detalles sobre las características y cómo mantener el Product Backlog.

El cuidado del Product Backlog también se conoce por los siguientes nombres:

• Priorización del Backlog,
• Refinamiento del Backlog,
• Escalado del Backlog.

Propósito del cuidado del Product Backlog

El Product Owner gestiona el Product Backlog. Las habilidades clave incluyen priorizar tareas a medida que se acerca su fecha de vencimiento. Esto se debe a que el objetivo del cuidado del Product Backlog es asegurarse de que las funcionalidades del Producto vengan con el mayor valor comercial, es decir, aquellas más esenciales desde el punto de vista del Cliente, estén en la parte superior de la lista de tareas. Y su descripción sea clara y detallada para que su implementación pueda comenzar justo en el siguiente Sprint.

El Product Backlog puede actualizarse diariamente si es necesario. El Product Owner puede agregar nuevas User Stories al Product Backlog después de hablar con los Stakeholders y el Equipo de Desarrollo, o sacando conclusiones y reformulando User Stories ya escritas en el Product Backlog.

La actualización obligatoria del Backlog es una de las tareas realizadas durante la Revisión del Sprint. Describimos ese proceso en detalle en este artículo. Generalmente, durante esta reunión, el Equipo Scrum discute no solo las tareas a completar en el próximo Sprint. También especifica preliminarmente las User Stories y su implementación en los próximos dos o tres Sprints. Esta forma de hacer las cosas permite que el Equipo Scrum y sus actividades tomen una visión más amplia de la dirección a largo plazo. Permite pensar en las tareas que se están realizando actualmente desde la perspectiva de su desarrollo en Sprints posteriores.

Errores en el mantenimiento del Product Backlog

Uno de los problemas más comunes respecto al cuidado del Product Backlog es permitir que se expanda de manera incontrolada. Esto se debe a que, mientras se trabaja en el Producto, diversas funcionalidades y tareas adicionales propuestas tanto por los Stakeholders como por los miembros del Equipo Scrum aparecen espontáneamente. Por lo tanto, limitar el crecimiento del alcance del Product Backlog (scope creep) es una de las tareas más importantes realizadas por el Product Owner. Los errores más comunes que cometen los Product Owners se refieren a:

1. Desviarse del Objetivo del Producto – agregar demasiadas ideas al Product Backlog más allá del Objetivo Básico del Producto no es una buena práctica, ya que reduce en gran medida su legibilidad. Es mejor recopilar ideas para funcionalidades adicionales en un documento separado.
2. Duplicación de contenido – ingresar ideas repetidas o muy similares de diferentes Stakeholders en el Backlog – antes de agregar otra entrada al Backlog, el Product Owner debe asegurarse de que la nueva entrada no duplique ninguna de las existentes.
3. Falta de una perspectiva más amplia – se deben ordenar las entradas del Product Backlog de acuerdo con su valor en relación con el Objetivo del Producto. Sin embargo, ten en cuenta que la priorización debe tener en cuenta los próximos varios Sprints para que las tareas realizadas en un Sprint dado estén perfectamente vinculadas tanto al Sprint anterior como al Sprint inmediatamente siguiente.

No puedes evitar errores de este tipo. Sin embargo, la conciencia de su ocurrencia puede hacer que el Product Owner sea más cauteloso al agregar nuevas User Stories al Product Backlog para encontrar el equilibrio adecuado. Esto se debe a que también es un error darle demasiado corte al Backlog y eliminar entradas que contienen tareas similares que difieren. Por ejemplo, describir funcionalidades de Producto similares que difieren significativamente en la aplicación.

Mantenimiento del Backlog vs. métricas utilizadas en Scrum

El Product Backlog contiene una descripción del trabajo restante a lo largo del proyecto. Sin embargo, solo un Backlog actualizado y regularmente cuidado puede estimar con precisión la proporción de la cantidad de trabajo completado respecto al total. Para representar la cantidad de trabajo completado, debes aplicar el Gráfico de Burn Down, del cual escribimos en este artículo.

Otra métrica popular para describir el trabajo del Equipo Scrum es la Velocidad. Puedes medirla comparando el número de entradas del Product Backlog convertidas en Incremento durante un solo Sprint. Describimos la Velocidad en más detalle en este artículo.

Resumen

El Product Owner realiza el Cuidado del Product Backlog. Cuando el Product Backlog está bien mantenido, el Equipo Scrum tiene una visión clara del trabajo que queda. También puede obtener una perspectiva más amplia y orientada al futuro de cómo se ve el camino hacia el Objetivo del Producto. Por eso, el Product Owner necesita asegurarse de que las User Stories incluidas en el Product Backlog estén en orden de prioridad para su finalización. Y también que las tareas a completar en los próximos Sprints estén descritas con el mayor detalle posible.

Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.