---

¿Qué es el Product Backlog de Scrum? ¡Puede que te sorprenda!

El Product Backlog de Scrum es el elemento central para gestionar todos los requisitos conocidos de un producto Scrum.

Contiene el trabajo emergente y ordenado necesario para mejorar el producto y alcanzar sus objetivos. Los requisitos incluyen los funcionales y no funcionales y otras características relacionadas con la experiencia de usuario y el diseño de la interfaz.

El Product Backlog contiene solicitudes de funcionalidades y sus historias de usuario generales. También puede incluir requisitos previos o complementarios, como crear entornos de pruebas y desarrollo, así como historias para resolver errores conocidos, reducir deuda técnica o mejorar funcionalidades.

Cada producto tiene un Product Backlog compartido por todos los equipos Scrum que trabajan en él. La Product Owner es responsable de crearlo, mantenerlo y ajustarlo. El Product Backlog no responde ni debe responder a cómo se desarrollarán y entregarán esos requisitos.

Eso corresponde al equipo Scrum, que decide y documenta en los Sprint Backlogs las tareas necesarias para abordarlos. Ten en cuenta que el Product Backlog y el Sprint Backlog son entidades físicamente separadas, aunque los elementos del primero determinan el contenido del segundo.

La responsable del Product Backlog Scrum es la Product Owner. El Scrum Master, el equipo y otras partes interesadas contribuyen para elaborar un conjunto más amplio de historias que lleven el producto al éxito.

Trabajar con un Product Backlog no impide crear y utilizar otros artefactos para gestionar el trabajo. Algunos ejemplos son un resumen de las funciones de los usuarios, descripciones de flujos de trabajo, pautas de interfaz, guiones gráficos o prototipos. Estos artefactos no sustituyen al Product Backlog, sino que complementan y detallan su contenido.

El Product Backlog es un documento vivo. Del mismo modo que el software mejora incrementalmente, el Product Backlog también crece con el tiempo. El marco Scrum no exige en sí mismo un proceso independiente de gestión del cambio. La Product Owner crea las primeras versiones del Product Backlog a partir de su mejor comprensión inicial del producto.

Mientras observa cómo evoluciona el producto de un Sprint a otro y amplía sus conocimientos sobre las necesidades del cliente, añade, elimina y ajusta los requisitos del Product Backlog.

La Product Owner prioriza los requisitos del Product Backlog. Cuanta más prioridad tiene un elemento, más detalles debe contener. Así el equipo puede comprender fácilmente los requisitos prioritarios y crear las tareas necesarias para desarrollarlos.

Además, los Developers estiman el tamaño de los elementos cuando es necesario; los puntos de historia son una técnica opcional. Las estimaciones de las historias prioritarias deben ajustarse y mejorarse para prepararlas para la Sprint Planning.

Cada Product Backlog tiene atributos que lo diferencian de una simple lista de tareas:

• Cada historia aporta valor empresarial o técnico al cliente, al responsable del negocio y a los usuarios finales,
• Todas las historias se priorizan y ordenan de mayor a menor prioridad,
• El nivel de detalle de una historia depende de su posición en el Product Backlog,
• El tamaño de las historias se estima cuando es necesario mediante una técnica adecuada,
• El Product Backlog es un documento vivo,
• El Product Backlog describe el trabajo del producto; el plan detallado de ejecución de los Developers pertenece al Sprint Backlog.

Las historias aportan valor al cliente, al negocio y a los sistemas

Cada historia del Product Backlog debe ofrecer algún valor al cliente. Las historias sin valor para el cliente desperdician recursos y deben eliminarse. El Product Backlog puede incluir historias para:

• Especificar requisitos funcionales y no funcionales,
• Resumir el desglose general del trabajo necesario para lanzar el producto,
• Configurar entornos de desarrollo y demostración ajenos a producción,
• Corregir defectos.

Ejemplo de Product Backlog de Scrum

Algunas tareas quizá no aporten valor directo a la funcionalidad o al cliente empresarial. Aun así, deben aportar valor al aumentar la calidad, reducir la deuda técnica y facilitar el mantenimiento a largo plazo.

El Product Backlog es un documento vivo

El Product Backlog es un documento vivo que cambia y evoluciona durante todo el proyecto. Si es necesario, se añaden historias nuevas y se modifican, detallan o eliminan las existentes. Los requisitos ya no quedan fijados al comienzo como ocurría con la metodología en cascada.

El conjunto final de requisitos se desarrolla de forma iterativa, junto con los incrementos de software que van surgiendo.

Esto difiere de la ingeniería de requisitos tradicional. Sin embargo, esta nueva forma de gestionarlos permite maximizar el valor para el cliente y minimizar el desperdicio de recursos.

Distintos niveles de detalle

Los requisitos del Product Backlog pueden tener distintos niveles de profundidad y granularidad. Solo deben definirse con mayor detalle los requisitos que se implementarán en los próximos Sprints. Las demás historias deben mantenerse generales y abordarse «justo a tiempo», antes de que el equipo necesite conocerlas mejor.

No tiene sentido invertir tiempo y recursos en especificar requisitos que pueden cambiar o desaparecer antes de necesitarse su implementación. Tratar los requisitos «justo a tiempo» es una de las grandes ventajas de Scrum para gestionar aquello que ni siquiera sabemos que desconocemos en los proyectos.

Sin tareas de bajo nivel en el Product Backlog

El Product Backlog suele describir el trabajo del producto y no el desglose detallado de tareas para realizarlo. La Product Owner define los requisitos con clientes y partes interesadas antes de llevarlos al refinamiento o a la Sprint Planning. Los Developers son responsables del desglose detallado y de organizar su trabajo.

El Product Backlog se ordena por prioridad

Todas las historias se priorizan y el Product Backlog se ordena de mayor a menor prioridad. La Product Owner lo hace con apoyo del equipo. El valor añadido para el cliente, los costes, los riesgos y las dependencias son los factores más habituales que se consideran. Esta priorización permite decidir qué debe desarrollar y entregar el equipo a continuación.

Estimar el tamaño de los elementos

Los Developers pueden estimar el tamaño mediante una técnica acordada, como puntos con una escala de estilo Fibonacci o tamaños relativos S/M/L/XL/XXL. Scrum no exige una escala concreta ni estimar todos los elementos lejanos. Trataremos esto más adelante. Estas estimaciones influyen en la planificación de capacidad, el contenido del Sprint Backlog y los planes de lanzamiento.

Trabajar con el Product Backlog

El Product Backlog requiere cuidado y atención periódicos. Debe gestionarse cuidadosamente porque es la fuente de referencia para comprender en qué consiste tu producto de software.

Al comienzo contiene muchas historias generales que pueden ser o no muy relevantes para el éxito del proyecto. A medida que el proyecto avanza de un Sprint a otro, la Product Owner y el equipo aprenden más sobre él.

Así, el contenido refleja cada vez mejor el producto y lo que ha aprendido el equipo.

Después de la configuración inicial, el Product Backlog debe mantenerse continuamente. Este mantenimiento consiste en:

• Describir y añadir los requisitos que se descubren, y modificar o eliminar los existentes cuando corresponda,
• Ordenarlo por prioridad, situando arriba las historias más importantes,
• Preparar las historias prioritarias para las próximas Sprint Plannings, normalmente durante el refinamiento,
• Estimar o volver a estimar las historias, normalmente durante el refinamiento.

La Product Owner es responsable de mantener siempre el Product Backlog en buen estado. Sin embargo, mantenerlo es un proceso colaborativo. Debe reservarse una parte razonable de la capacidad de los miembros para el refinamiento continuo y el tiempo necesario para los eventos de Scrum.

Además, este mantenimiento colaborativo aclara los requisitos y favorece que los miembros se impliquen en el producto que está surgiendo.