The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog,(s)he is the one who prioritize it based on the customers feedback or business value.
Why Product Backlog is important
It is prepared so that estimates can be given to each and every feature.
It helps in planning the roadmap for the product.
It helps in re-ranking the features so that more value can be added to the product.
It helps in determining what to prioritize first. Team ranks the item and then builds value.
Characteristic of a Product Backlog
It is a very active document where all the wishlist and user requirements are gathered
Product owner makes sure that content of product backlog “user stories” are defined in detailed level
user story in product backlog should be enough in sizing to be fit in one sprint
All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
The product backlog acts as an input to the sprint backlog when comes to functionality
There are also bugs/issues, epic, user stories and themes are included in the product backlog
There are also bugs/issues, epic, user stories and themes are included in the product backlog
To put it short: The product backlog is the wish list for the product for the whole lifecycle. It defined with its detail nature what to be implemented.
Techniques Used To Maintain Product Backlog Effectively
DIVE
Product backlog items are prioritized in linearly ordered based upon DIVE criteria
Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
Insure against risk (business and technical)
Business Value
Estimated Effort
DEEP
Detailed
Estimated
Emergent
Prioritized
INVEST
Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable A user story must deliver value to the end user.
Estimable You must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable The user story or its related description must provide the necessary information to make test development possible.
What may influence a product owner's prioritization?
Customer priority
Urgency of getting feedback
Relative implementation difficulty
Symbiotic relationships between work items (e.g. B is easier if we do A first)
While the product owner is tasked with prioritizing the backlog, it's not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone's workload and the product delivery.
What is sprint backlog
There are also bugs/issues included in the sprint backlog for each sprint. Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Owner set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in timebox.
Characteristic of a Sprint Backlog
Sprint backlog is dynamic in nature,each sprint the above scenario is repeated. Good practice is to keep the sprint backlog aka sprint goal as static as possible during a sprint.
During each sprint planning session, the team returns back to product backlog to pick recently prioritized user stories for the sprint.
Sprint backlog is a subset of product backlog
Sprint backlog is an output of a sprint planning meeting.
In Sprint backlog, scrum team works on how the user stories would be implemented in a sprint by dividing it further into tasks and estimating it.
Assuming Product Backlog has stories: 1, 2, 3, 4 , 5 and 6. The team decides to do stories 1,2 and 4. As during sprint planning team realized that there still some question which is not answered well by the Product Owner, so they decided not to include the user story no: 3 and jump to user story no:4, which was defined well.
Sprint backlog is owned by the Development Team and contains what and how it get’s delivered
Lastly in sprint backlog team implementing (converting) the most prioritized product backlog items into working software. For each iteration (sprint) the team creates a new plan, based on what is in the top of the Product backlog when starting the sprint.
9 Tips for Creating a Good Sprint Backlog
1. Involve every team member in the process 2. Discuss how every item should be implemented 3. Have a definition of done 4. Identify all kinds of tasks 5. Don't estimate tasks at all 6. Don't assign tasks up front 7. Review the sprint commitment 8 Don't use too much time 9. Evolve the Sprint Backlog during the sprint