Artefactos de Scrum. Product Backlog

24 de agosto de 2015

El Product Backlog es un listado priorizado de todo aquello que podría ser necesario realizar para completar el proyecto. La palabra podría refleja la verdadera esencia del Product Backlog, pues es un elemento vivo y en constante evolución y lo que hoy puede constituir el elemento más importante a desarrollar para el proyecto podría ser eliminado mañana si resultara necesario.

El Product Backlog es un listado priorizado de todo lo que podría ser necesario a lo largo del proyecto que se mantiene vivo y en constante evolución.

Su propietario y único responsable es el Product Owner. A él corresponde su generación y es habitual que elaborare una primera versión durante lo que se conoce como Sprint 0 (Sprint Cero), el primer Sprint del proyecto y cuyo objetivo consiste en disponer todo aquello que sea necesario para que el equipo de desarrollo pueda iniciar su trabajo.

El Sprint 0 no es un sprint ordinario por lo que no cuenta con el resto de eventos habituales de un Sprint y carece también de una duración determinada. Podríamos decir que el Sprint 0 es todo el período de tiempo que transcurre desde la idea inicial del proyecto hasta que éste es definido por completo, son cerrados el contrato y el resto de condiciones con el cliente y se acaban de concretar todos los preparativos para que el equipo de desarrollo esté listo para llevar a cabo su primer Sprint.

Es muy importante que sea el primer elemento del proyecto en ser generado, antes de definir la tecnología que se empleará para el desarrollo del mismo, la arquitectura a emplear o, incluso, la contratación del equipo si fuera necesario contratar. La propia contratación de un arquitecto podría ser uno de los primeros ítems del Backlog, el cual llevaría a cabo la tarea de decidir la arquitectura, que sería un elemento del Backlog de menor prioridad que el de la contratación.

La pronta definición del Product Backlog será la pieza clave que permita generar un pronóstico de la planificación de todo el proyecto de forma empírica, es decir, basado en medidas reales en lugar de especulaciones.

El Product Backlog se mantendrá vivo mientras exista el proyecto, ya sea para definir sus nuevas funcionalidades a desarrollar o los evolutivos y correcciones durante la fase de mantenimiento. El Product Backlog nunca estará completo y su primera versión tan sólo pondrá de manifiesto los requisitos inicialmente conocidos y mejor entendidos.

El Product Backlog debe ser la única fuente de requisitos del proyecto y debe recoger las referencias a cualquier otro tipo de herramientas que se utilicen para definir las tareas como, por ejemplo, enlaces o referencias a herramientas de diseño y modelado con las que se hayan desarrollado los diseños o wireframes necesarios para que el Equipo de Desarrollo sepa cómo realizar sus tareas.

Como ya explicado en la sección de las reuniones de grooming, el Product Backlog es dinámico, es decir, permanece en constante evolución a lo largo de todo el proyecto para poner de manifiesto aquellas necesidades que lo sitúen como atractivo y superior frente a productos de la competencia.

Sus elementos cuentan con atributos de descripción, prioridad, estimación y valor y distintos equipos de Scrum que trabajen en el mismo proyecto podrían y, de hecho deberían, compartir el mismo Product Backlog e, incluso, el mismo Product Owner.

Los elementos del Product Backlog de mayor prioridad suelen ser más claros y estar definidos a un mayor nivel de detalle, es decir, suelen ser elementos con un menor grado de incertidumbre o representar incertidumbres acotadas. Por ejemplo, un elemento de alta prioridad del Backlog podría consistir en aprender a empaquetar una aplicación Web para Android mediante el framework Apache Cordova, mientras que uno de baja podría ser, simplemente, que el proyecto cuente con aplicaciones mobile.

Key Points
Es un listado priorizado de todo lo que podría ser necesario completar durante el proyecto.
Permanece en constante evolución a lo largo de todo el proyecto.
El Product Owner es su propietario y único responsable.
Su primera versión se elabora durante el Sprint Cero.
Debe ser el primer elemento del proyecto en ser generado.
Tan pronto como sea definido se podrá generar un pronóstico de la planificación de todo el proyecto de forma empírica.
Es la única fuente de requisitos del proyecto.
Sus elementos cuentan con atributos de descripción, prioridad, estimación y valor.
Distintos equipos Scrum que trabajen en el mismo proyecto deberían compartir el mismo Product Backlog y el mismo Product Owner.
Sus elementos de mayor prioridad suelen ser más claros y estar definidos a un mayor nivel de detalle.