Es una lista de Historias de Usuario, ordenadas según el valor de negocio que establece el Dueño del Producto, y que trata de cubrir todas las funcionalidades necesarias.
El product backlog se puede ver desde la perspectiva de una iteración o sprint, de una release o de todo el producto. En cualquier caso sigue siendo una lista priorizada de historias de usuario más o menos detalladas, aunque hablemos en cada caso de sprint backlog, release backlog o product backlog.
¿Para qué sirve?
- Se hace para tener una perspectiva de todo lo que se quiere hacer y tener claras las prioridades del cliente.
- Ayuda a que el equipo sea más autodisciplinado y respete las prioridades del cliente.
- También permite que el cliente pueda introducir cambios durante la vida del proyecto.
- Ayuda a manejar la incertidumbre durante el proyecto porque empuja a describir con más detalle las historias más importantes y a relativizar la importancia de detallar historias de menor prioridad.
- Es más ligero que un documento de requisitos exhaustivo.
¿Cómo se hace?
- Las historias de usuario de mayor prioridad estarán más detalladas que las que se abordarán más adelante.
- Se revisa frecuentemente (en la reunión de revisión del backlog)
- Es frecuente agrupar las historias usando el método MoSCoW.
- “imprescindibles” (Must have),
- “importantes” (Should have),
- “interesantes” (Could have) o
- “opcionales” (Won’t have now but Would be later).
- Nuestro compromiso con el cliente es desarrollar en este orden.
Malas prácticas:
- Considerar la pila de producto como un contrato. Sólo es una herramienta de planificación.
- Cambiar prioridades sin el consentimiento del dueño del producto.
- Introducir en el backlog historias de deuda técnica. Los defectos del equipo no los paga el cliente, sino que reducen la velocidad.
- Preocuparse por describir con mucho detalle historias que están muy abajo en el backlog.
- No actualizar el plan de releases (¿qué pretendemos entregar en cada nueva versión?) cuando introducimos nuevas historias o reestimamos las existentes.
Para ampliar:
- El libro “Agile Estimating and Planning” de Mike Cohn.
- Prioritizing the Product Backlog (artículo en el blog Agile Software Development)
PUBLICIDAD:
Si estás interesado en recibir formación, puedes leer sobre los cursos que ofrezco o ponerte en contacto conmigo.