Refer & Earn

Product Backlog

product backlog

Product Backlog

Satisha Venkataramaiah
23rd Mar, 2020

In a restaurant, at a peak time of the day, there will be a lot of hungry people waiting to get served. The server collects the orders from each of the customers and then pass it on to the kitchen. In the kitchen, orders are piling up, which needs to be cooked and sent for delivery. 

The food orders are the list of things that needs to be prepared next. It needs to be prioritized appropriately so that the same items can be cooked together, people who ordered first should get it first, and so on.


The list of food orders in the kitchen is known as Product Backlog. A product backlog is an ordered list of everything that is known to be needed in a product. It is a single source of requirements for any changes to be made to the Product. You can also call it a single source of truth of all that happens in a Product. 


What does Product Backlog contain?

The Product Backlog has all those required for a product. It could be new features, bugs, change requests, enhancements, functions, product feedback from customers, and everything else.

Every single item in the Product Backlog is called a Product Backlog item. Irrespective of what the item type could be, in Scrum, it will be called as a Product Backlog Item. 


Who owns the Product Backlog?

The Product Owner is the responsible person for the Product Backlog. He/she owns the availability of the Product Backlog, it's contents, and it's ordering based on business priorities. Anyone in the Scrum Team can add items to the Product Backlog, but the Product Owner decides the priority of the issues and orders them accordingly. The Product Owner owns the Product Backlog.  


Then Product Owner orders the product backlog items by using different techniques that can maximize ROI. 


What is the maximum size of the Product Backlog?

There is no fixed size for a Product Backlog, and it can never be complete. It starts with the initially known and best-understood requirements from the Product context. As the product hits the market, more is learned from the users, market dynamics, feedback related to the product, and much more. 

As more is discovered, the list will become exhaustive. Requirements will never remain constant. It continually changes with the ever-changing market needs. Any change in business requirements, market conditions, or technology can cause changes to Product Backlog. 


As long as the product exists, there will be a Product Backlog for it. The Product Backlog is dynamic and changes according to what the product needs to be, which is appropriate, competitive, and useful. 


How many Product Backlogs are there?

For a single product, there will be only one Product Backlog. As discussed above, its a single source of the requirement for the entire product. There will still be only one Product Backlog, even when different teams contribute to product development. While different teams may have different sprint backlog, there will only be one Product Backlog. 


Product Backlog Refinement

It is an ongoing process where the Product Owner and the Development Team work together in understanding the highly ordered Product Backlog items. They then add details, estimates, and order to the items in the product backlog. 

During this activity, the product backlog items are reviewed and revised. The Scrum Team decides how and when the refinement will happen. Backlog Refinement should not take more than 10% of the actual capacity of the Development Team. 


The product backlog items can be updated anytime by the Product Owner or at their discretion. The Development Team is responsible for estimating the Product Backlog items as they are responsible for coming up with the Product Increment. 

The higher ordered PBIs usually have more details and precise than the lower ordered ones. As the Product Owner decides the order of priority of PBIs, they typically have more clarity of the items. Estimates with precision can happen only on the items that have more clarity and precise details.  


Refinement usually happens on the ordered items whose chances of getting implemented in the next few sprints are high. The PBIs are refined in such a way that they can be completed within a Sprint. 

If they are too big or couldn't be done in a Sprint, they will be vertically split so that they could be accommodated in a Sprint. Only those PBIs which could be "done" within a Sprint is considered as "ready" for selection in Sprint Planning

About the author
Satisha Venkataramaiah

Satisha is a Founder and CEO of leanGears and Leanpitch. He is a passionate product owner who spends most of his time building products for Startups and Product Managers. He loves solving problems that make life of every living being on this earth easy. He strongly believes in collaborating with customers to build simple and valuable products rather than building sophisticated fancy products. He has built products such as leanGears and StartupPlanner. Based on his experience and learnings, he has authored two books: Creating the culture of Happily Delivering Happiness and Who is Product Owner.

Follow on:

This website uses cookies to improve your experience. See our terms and conditions to learn more.