Dentro de un proyecto, sólo debe haber un backlog correspondiente a un solo producto.El backlog del producto es propiedad y está gestionado por el propietario del producto. Es un documento vivo con una lista de deseos proiorizada que crece y se perfecciona a una cadencia regular para asegurar que el equipo de desarrollo se centra en la finalización.
Sirve como una lista ordenada y emergente de las necesidades del usuario más todo lo que se requiere para cumplir con la visión del producto.Cada elemento se denomina elemento del backlog del producto -PBI.
PBI, puede expresarse en forma de
- Historia de usuario
- Mapa mental
- Caso de uso
- Historia de impacto
- Descripción de características
Tiene elementos centrados en el cliente -típicamente historias de usuario-, los prioriza y los añade. Las características se miden y desarrollan en función de las historias de usuario, en lugar de las líneas de código. En cualquier momento, el backlog del producto no está completo, es de naturaleza dinámica que enumera
- Características
- Funciones
- Requisitos
- Mejoras
- Defectos
- Asuntos de trabajo
- Correcciones
que constituyen los cambios que se realizarán en el producto en futuras versiones. A medida que un producto se utiliza y adquiere valor, el mercado proporciona retroalimentación, el backlog del producto se convierte en una lista más grande y exhaustiva. Los requisitos nunca dejan de cambiar, por lo que el backlog del producto es un artefacto vivo.
El backlog de la versión es un subconjunto del backlog del producto que se planea entregar en la próxima versión. Es gestionado por el PO.Dentro de un proyecto, puede haber múltiples lanzamientos.Se crea un backlog de lanzamiento para cada lanzamiento. Múltiples sprints pueden culminar en una versión.
El backlog de sprint es una lista detallada de las historias de usuario que se espera hacer en el horizonte de la caja de tiempo. Se crea para cada sprint. Se hace colectivamente como una previsión por el equipo de desarrollo para dar cuenta del trabajo necesario para hacer un incremento hecho.Plamned con suficientes detalles y surge durante el sprint.Cada elemento dentro del sprint backlog, dispensa la idea de tener algo potencialmente shippable.
Cuando los elementos del plan se consideran innecesarios, se eliminan . Al final de cada sprint,el producto está listo para ser entregado al cliente o ser mostrado a la parte interesada. Cuando el elemento es aceptado por el PO y se cumple la definición de hecho, el elemento pasa a la sección de incremento de producto y se dispensa como producto potencialmente enviable. Cada incremento es aditivo a todos los incrementos anteriores y se prueba a fondo. En cualquier punto del sprint, se puede sumar el trabajo total que queda en el Sprint backlog.