Document: Product Backlog

What is the work for the next sprint to get the product? 

• The Product Backlog is a Scrum artefact that holds all required work to be completed in the next two or three sprints, either with having business value or not (eg. technical debt)

• the Product Backlog is organized as an ordered list of user stories, the most important stories on top, while leaving below those with lower importance (in the middle) and finishing with the epics at the bottom. Epic are big, complex user stories that must be decomposed into short user stories.

In this example we have 4 columns:

1. user story brief description of the functionality required
2. value Product Owner’s assessment of the business value at this point in time
3. complexity the team’s assessment of the complexity of the story using Low, Medium, High scale
4. sprint suggestion in which interaction this story will be done?

• In this example all the entries are product features with business value, but PBIs can be of many types:

1. product features
2. work to repay some technical debt
3. exploratory work (“spikes”) to test some technolgy or approach
4. bug fixing

• The different types of work listed above show that how the work around the product can be and should be documented in the Product Backlog because it is the single source of truth for all requirements for any changes to be made to the product

• The ideal Product Backlog should be DEEP:

1. Detailed appropriately
2. Emergent
3. Estimated
4. Prioritized

• The Product Backlog is owned by the Product Owner and is dynamic: it changes to identify what the product needs to be appropriate, competitive, and useful

• It is the responsibility of the Product Owner to organize the work to be done in the next sprint on top of the Product Backlog

• A Product Backlog is never complete, it evolves with the product and the environment evolves and new requirements emerge

• From the top of the Product Backlog the Scrum team selects work to refine and later compose their Sprint Backlog