So far, we have learned about the Scrum Team and Scrum Events. We understand that there are requirements that the team works on, but do we know what all constitutes these requirements? How do we ensure that we work on the right set of requirements? In this tutorial, we will discuss Product Backlog, which will answer all the questions on product requirements. We will cover the below topics -

• What is a Product Backlog?
  • What all makes a Product Backlog?
  • Characteristics of Product Backlog
  • Product Backlog Refinement
• Common Questions on Product Backlog

What is Product Backlog?

The Product Backlog is a prioritized list of all the functionalities that we need in the product. It's a single source of truth for all the product requirements. The team is not supposed to work on anything that is not on the product backlog. The Product owner is responsible for managing the backlog. The Product backlog helps in monitoring the progress towards goals. The backlog helps in determining the work remaining, which we usually do at the end of every sprint.

What all makes a Product Backlog?

The product backlog consists of Features, Change Requests, Defects, Technical Improvements, Proof of Concepts, etc.  Let's understand it by examples.

• Features - As a Customer, I want to enhance the login capabilities to use social media so that users can log in using their Facebook, Twitter, and Google accounts.
• Change Requests - As an IT Support executive, I want the default sorting of support tickets to changed from Aging to Priority so that top priority tickets can be looked at first.
• Defects - Fix Defect # 123 in Jira so that the customers' accounts don't get locked on the first invalid attempt.
• Technical Improvements - Upgrade the System to Java 11 so we can utilize all the features that Java 11 offers.
• Proof of Concept -  Analyze cloud features of AWS, Azure, and Google Cloud and do a quick proof of concept to identify which cloud platform is best suited for the application

As you can see, everything from new functionality to defects to even analysis and POC is part of the product backlog. It ensures that there is nothing that the Scrum team would ever need to work on, which is outside this list.

Characteristics of Product Backlog

We now know what constitutes a Product Backlog, but do you know what makes a good (or a bad) product backlog? Let's go through some of the characteristics of the product backlog.

• Detailed - Product backlog items should have sufficient enough details so that the team could pick them up in the sprint. But do all its items are detailed? No !! The Product roadmap is usually long-term, like six months one year, or even more. You don't expect every detail to sort out. A Product backlog will always have some high-level functionality that the product needs to have, but there is less clarity at this point. So what do we do? Well, the backlog items that need to be worked immediately (like in the next few sprints) should be detailed enough, while the ones which we have to take up later, can be high level. The expectation is that by the time it will be picked up, the Product owner will have more details on these requirements.
• On-Going - This could sound odd, but a product backlog is never complete. It evolves based on the needs of the product, and more feedback becomes available. E.g., a new feature needs to be added based on competitor analysis. Or an existing feature needs to be updated based on customer feedback. The Product Backlog is a living artifact, which will keep getting updated based on business requirements, changes in market conditions, or technology upgrades.
• Estimated - Each Product Backlog item has an estimate which is done by the development team. This estimate is used by the Product owner to determine how much time it will take to complete that functionality. It also helps him to make a call on the priority of the backlog item.

The accuracy of the estimate depends on how detailed the requirements are in the backlog. The functionalities for which we have more clarity are broken down into smaller chunks (stories) and estimated at the story level. The items which are not very clear estimate at a high level (usually at the level of an epic)

• Prioritized - The product backlog items need to be ordered by priority. The ones at the top are of the highest priority, and the ones at the bottom are of the lowest priority. Who determines this priority? The Product owner! Likely, the product owner might not have clarity and detailed requirement for all the backlog items. However, one should do the prioritization rightly for the items that need to pick up in the next few sprints.

Usually, we have releases or phases of product development. E.g., we could have four quarterly releases (each release having six sprints of 2 weeks each). In such cases, the prioritization happens first for the release that is immediate and followed by the next release. There is no point in working on the prioritization of release 4 when release 2 prioritization is pending.

Product Backlog Refinement

We know that the product backlog needs to be detailed, ongoing, estimated, and prioritized. But how do we do that? And more importantly, when do we do that. How do you get time from the development team for this activity?

This entire process is Backlog Refinement (also referred to as backlog grooming). The development team spends no more than 10% of the time on backlog refinement. This effort gets embedded in the overall sprint effort.

Who Does the Refinement?

Product refinement is lead by the Product Owner and attended by the Scrum Team (Scrum Master and the development team). Also, the internal and external stakeholders get an invitation as needed. It ensures that everyone is on the same page, and there is a shared understanding of product requirements.

The development team will help the product owner to estimate the items where there is sufficient clarity. The product owner will try to break more significant functionalities into smaller pieces as more details become available. The prioritization of items where details are available will also cover in this meeting. However, the product owner is free to change it later.

When does Product Refinement happen?

The Scrum Guide doesn't detail out when the product refinement should happen. What we know is that the product backlog is an ongoing item, which would mean that refinement should also be continuous. We also know that the development team should set aside up to 10% of the time for this activity.

It means that the planning for product refinement gets left to the product owner and the scrum team. They can set it up the way it works best for them.

Some teams prefer to have one long session, more like a workshop of a few hours. It works exceptionally well if we need to invite external stakeholders who can't be regular attendees. On the other hand, it's also common for some teams to have shorter duration refinement sessions, which are more frequent.

Definition of Ready

We know that the team needs to pick up backlog items to work on during the sprint. How do we know which ones to pick? It's based on backlog priority. But how do we ensure that the items that we pick have got enough details?

It happens by marking the product backlog items as "Ready". When can we mark a backlog item as Ready? Below are some of the considerations:

• The backlog item has detailed enough requirements and acceptance criteria (test descriptions) that will prove the acceptance of backlog items.
• Any Non-functional requirement has a clear definition. It can include performance, security, operational requirements, etc.
• The development team has clearly understood the requirement.
• The backlog item is small enough to complete within the sprint. If not, it's always advisable to split the backlog item into smaller pieces.

During the Sprint planning meeting, the development team considers the backlog items which are in ready status, and from that list, the team decides what all we can pick up in the sprint.

It ensures that the team always has a clear list of what is ready in the backlog, and this helps to have a collective view of what backlog items need to work upon during refinement. It's also important to note that at any point in time, the team should have sufficient backlog items that are refined and in a "ready" state. Otherwise, the team will not have enough to work on during the sprint. A healthy product backlog is one where the backlog items in the ready state are enough for at least the next 2-3 sprints or more.

Common Questions on Product Backlog

Let's go thru some of the common questions that people have on the product backlog.

Can Multiple teams work on one product backlog?

Yes, and it's a pretty typical scenario. We can have multiple scrum teams that work on a single product backlog. If a product is reasonably significant, and only the scrum team cannot do it, this will often lead to the creation of multiple scrum teams. It is a more efficient way of handling products with a broader scope.

Usually, the team uses some sort of tags or other tool features to determine which high-level functionality a team will pick up. It's always a useful functionality to have epic (high-level functionality) distribution between these teams. It ensures the team doesn't step into each other's functionality.

Can one teamwork on multiple product backlogs?

An organization can be working on a great product that can have several sub-products. E.g., the Microsoft Office suite is one product, but it has several sub-products like word, excel, etc.

That means Microsoft office products will have several product backlogs, one for each sub-product.

In such cases, the best way is to have a single team (or multiple teams) work on one product backlog. That way, each team will work on a single product backlog, which is way more efficient.

In rare cases, we can have some common components like licensing (which is common across all sub-products) where one team might end up working with multiple product backlog items. It, however, is rare, and we don't encourage it unless essential.