Introduction
According to the
scrum guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The
product owner is responsible for the product backlog, including its content, availability, and ordering.
Image Source – educba.com
Here are some key points to remember for the product backlog:
- Ordered and emergent list of features/functionality that might be needed in the product
- The product backlog is dynamic and never complete. product backlog exists as long as the product exists.
- Each product backlog item has an order, value, estimate, and description.
- Product backlog items are ordered based on business value, cost of Delay, dependencies and risk.
- Product backlog items at the top of the product backlog are “small”, well understood by Team, “Ready” for Development and can deliver value to the business.
- Product Owner owns product backlog and is ultimately responsible for the contents and state of it.
- The product owner ensures that product Backlog is visible, transparent and clear to all.
- Anyone can add items to the Product Backlog, but the product owner has the final authority and control on whether it stays there.
- The Product Backlog is a living artifact. Changes in business requirements, market conditions or technology may cause changes in the product backlog.
- 1 product backlog for 1 product; multiple teams working on the same product use the same product backlog.
Product Backlog Refinement
Product Backlog refinement is an ongoing process in which the Product Owner and Development Team collaborate on the details of the Product Backlog items.
Product Backlog refinement may include:
- Adding or removing items to the Product Backlog.
- Ordering/Re-ordering items in the Product Backlog.
- Estimating Product backlog Items (PBI)
- Reviewing, Revisiting PBIs
- Splitting PBIs into smaller PBIs
- Merging PBIs into larger PBIs.
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog Items can be updated anytime by the Product Owner or at the Product Owner’s discretion.
Product Backlog items that the Development Team may work on in the upcoming1-2 sprints are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in Sprint Planning.
In the above image, you can see that Product Backlog consists of User Stories and when we do Sprint Planning, we bifurcate these into Tasks and once these Tasks are “Done”, then they create a Working Software.
Along with what I have explained earlier, I would like to give you some points to think about:
- How often is the Product Backlog refinement done in a sprint?
- What happens if appropriate Product Backlog Refinement is not done?
Let me ask you a question here:
How many apps do you have on your smartphone? And how many of them do you use every day/month/year?
I have asked this question because this will give us the answer to why prioritization is important. We may not understand the relevance of prioritization, but it is an important exercise in Scrum. Since Scrum focuses on Working Software over Comprehensive Documentation, this exercise helps us in achieving the same. The below image is explaining that most of the features and functions are never used and only 7% of them are the ones which we use always.
Happy Learning!