Product Backlog

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 passes it on to the kitchen. In the kitchen, orders are piling up, which need 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 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, its contents, and its 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.  

The 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, it's 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 backlogs, 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 orders 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 are more precise than the lower-ordered ones. As the Product Owner decides the order of priority of PBIs, they typically have more clarity on 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 are considered as "ready" for selection in Sprint Planning. 

This is just a speck of knowledge on your journey to becoming an expert in the industry. If you have any doubts or require career guidance, feel free to connect with our Industry experts and trainers for 1-on-1 coaching. 

"We upskill and boost your career by providing a wide range of courses such as CSPO, CSM, ICP-ACC, etc. visit our website to learn more about all the courses we offer."