What Is Product Backlog and Who Owns It?

What Is Product Backlog?

Scrum backlogs list all the work that you need to complete. It’s where you store things you need to do in the future.

Specifically, a product backlog is a list that includes user stories, new features, changes to existing features, and bug fixes. It also contains items that help teams achieve specific outcomes. 

Nothing gets done unless it’s on the product backlog. However, just because you note something doesn’t mean you’re obligated to deliver it. 

It only represents an option for providing certain things rather than commitments.

It should be straightforward to add an item to the product backlog. Moreover, removing an item from the backlog should be equally simple. 

When organizing your product backlog, you must rank the items by priority. The highest-ranking items represent the team’s most essential to completing the task.

The size and detail of a product backlog item can vary based on the time frame you need it. 

Working on an item should contain enough information for the team to start working immediately. 

However, suppose these items do not have any specific timeframe. 

Their outline needs to remain broad with little detail in such a case. That assures you can carry over into other projects as needed or desired.

Product backlog items continuously change as the team members better understand the outcome.

These changes include adding or removing product backlog items and refining existing ones.

Such a process gives the dynamic characteristic to any project/product development.

Regarding the product backlog, a team may have various people with different roles. 

The person responsible for maintaining everything related to this list is called the “product owner.” 

Bonus: Click here to learn about the roles and responsibilities of a product owner.

This position requires keeping track of what items you can remove once completed or need no longer be on there for whatever reason.

Changes within teams, such as the inclusion of new members or changes in the objectives, should also be reflected by changing the respective priorities. That helps everything stay up-to-date.

Who Owns Product Backlog?

The product owner owns and decides to prioritize the product backlog. 

It would be best for every member from across the cross-functional teams to contribute to the backlogs. 

Another thing to remember is that the owners and purposes change based on the team’s approach. 

For example, the owner of the sprint backlog in the scrum is the delivery team. 

Who Makes the Final Decision on Prioritizing the Product Backlog?

In scrum, the product owner (PO) is the sole person responsible for prioritizing stories within the product backlog. 

Even though the PO makes the final decision on prioritizing the product backlog, it doesn’t mean the product owner is alone in this task. They can ask for whatever help is required. 

It would be best if you understood that the product owner is a proxy for the customer. 

The more they understand the customer’s needs, the better their project will be in terms of cost-effectiveness and sustainability.

They should maintain close contact with their customers to collect all necessary information about how they would like this new product or a feature to develop.

Talking to other stakeholders can also give them some insight – there must be no surprises during development.

It only takes one major change request at an expensive time near the launch date to set things back by weeks, if not months, without proper planning beforehand.

The product owner is the single person responsible for deciding the priorities at the end of the day. That is why you shouldn’t ever have multiple product owners.

There has to be a single point of truth for decisions– the product owner.

So then, where does the scrum master fall into all of this?

Think of the scrum master as the team’s leader.

Bonus: Click here to get an understanding of a scum team.

They must remain impartial to all matters of product design and decision-making but still push back against any obstacles that may inhibit a productive workflow on the project.

They’re like moderators in this way. They cannot play favorites with members of their team or interfere in case of disagreements about how best to move forward.

Suppose they do venture too deep into these sorts of discussions. In that case, it will only serve as an impediment when trying to solve problems alongside their teammates.

Their time would now get split between two responsibilities rather than just one.

The scrum master will always help the product owner in the process. However, they will not get involved in the final say themselves.

Preventing the scrum master from prioritizing is the same logic as why a project manager and a scrum master should never be the same person. 

Many companies will try this because they want to perform agile practices without changing their old values, processes, or organizations. But it doesn’t work like that.

How Long Does the Product Backlog Exist?

The product backlog exists and changes throughout the development of the product.

It lasts till the lifetime of the product. 

Who Can Order the Items in the Product Backlog?

The product owners order the product backlog.

They work with the stakeholders, the development team, and the scrum team to plan and analyze the work. 

The PO and the scrum team need to work together to give the development team a proper plan for the product backlog. 

What Are the Characteristics of a Good Product Backlog?

Following are the four characteristics of a good product backlog.

You can keep the acronym DEEP in mind and understand if your product backlog fits in. 

Detailed Appropriately

One of the critical characteristics of a good product backlog is that it will be detailed enough. 

The product backlog items you should take up later will have fewer details than the ones prioritized. 

Emergent

The product backlog is a constantly evolving document. The teams and the product owners may add items and other relevant information whenever they discover it.

They might also decide to change or delete a few things too. 

If the product backlog you are working on is changing, that’s the characteristic of a good product backlog. 

Estimated

A good product backlog must have a significant size estimation. And this estimation must be about the efforts that the team will require to develop them. 

This way, the product owner can easily visualize, estimate, and prioritize the item accordingly. 

For example, the team’s product backlog items to be prioritized will be small in size. 

Prioritized

A single product backlog must be a collection of various product backlog items. But in this case, you must not put each product backlog item at the top. 

When a situation like this pops up, it would be best to take the product items you require for release. Don’t focus on the other product backlog items. 

This way, you save time and can concentrate on your priorities. 

How to Estimate Product Backlog?

Estimating a product backlog helps product owners and teams to reanalyze the backlog items. 

You can use the following three estimation methods to estimate the product backlog.

Planning Poker

As the name suggests, this product backlog estimation is also fun to work with.

Once you have a ranking scale in place, call your team members together. Now distribute the cards with ranking to each one of them. 

Read aloud the product backlog item that you need to rank. Each team member will select the card and rank the items. But, they will not reveal it till the product owner gives a heads up. 

Once everyone has chosen their rating of that item, the team will display the cards. 

If the estimations are similar, the group has agreed upon that status. 

But if the selected estimates differ, then the team needs to discuss it further.

Ordering

Another product backlog estimation is ordering. 

Each team member picks up a card with a particular product backlog item printed. Then, they put it on the desk. 

Next, the team places the items on either side of the desk by considering how the team member estimates them.

One side of the desk represents the high prioritized items. In contrast, the other side will have the lower priority items. 

Next, the other team member also picks up a card from the pile and put it where they deem fit. They can also move the existing card to either side. 

Once all the cards are stacked on the pile desk, and all members agree with their positions, you give a number to the product backlog items. This number gets assigned with the help of the Fibonacci scale. 

Give a ranking to the items by starting with the lower cards. For example, you give the smallest item a number 1, and as you move to the other side of the desk, the estimate would be 3,4,5, and so on.

Unique Method

One of the unique methods of product backlog estimation depends on the t-shirts you wear. 

Surprised? Don’t be.

Estimating this method is easy peasy. 

Here’s how you can do it: You may estimate the product backlog item based on the sizes of S, M, L, XL, XXL, and so on. 

This method is handy when you are unsure of number estimations or are still figuring out the project. 

However, note that you cannot use this estimation till the end. Once you are comfortable using the numbers, convert these t-shirt sizes into one of the above estimations. 

Who Creates a Product Backlog Item’s Estimate?

The development team or the DT is responsible for all estimates in the product backlog. 

But the DT needs to consult and discuss the product backlog items with the owner. 

What Are the Product Backlog Prioritization Techniques?

RICE: 

RICE scoring model is a prioritization framework designed to help product managers determine which products, features, and other initiatives make the cut. You can give the RICE score by ranking these items according to four factors. 

The factors form the acronym RICE are:

• Reach (the number of customers who would use this feature)
• Impact (how much it will improve your company’s bottom line or revenue)
• Confidence (the belief in our ability to deliver on that estimate)
• Efforts (resources required for development time/costs)

Using a scoring system like this can provide companies with three key benefits: 

1. Enabling better-informed decisions from less biased decision-makers. 
2. Helping defense choices when challenged by executives. 
3. Reducing risk involved with new ideas getting introduced into already risky environments.

MoSCow Method:

The MoSCoW method is a framework for effectively communicating to key stakeholders what and why you are working on specific features. 

MoSCoW stands for must have (necessary), should have (preferable but not necessary), could have (possibly beneficial or advantageous), won’t get right now.

It tends to be used by waterfall-based enterprises. However, it may work better in agile environments when time constraints make it challenging to complete the entire project simultaneously.

It helps critical stakeholders understand which backlog items are most important to focus on and saves time and energy by categorizing them more efficiently. 

Value vs. Effort

The value vs. effort prioritization method helps simplify everything by listing various features and initiatives.

It quantifies them with value and effort scores to accordingly determine their place on the matrix. 

The value vs. effort prioritization method is an excellent way for organizations to utilize their resources most effectively.

Besides, it stays true to company values and goals while delivering on customer promises. All of this will lead to increased revenue or growth if executed correctly.  

The features rank according to how much value they provide relative to the effort needed for implementation. 

You can measure it by ROI (return-on-investment) or the total cost involved per feature until full development. You can choose whichever seems more appropriate given specific circumstances.

1-2-3 Later

The product owner looks through all the product backlog items three times.

The first time, they try to find the most important item on which work should be done next and set it aside while inspecting other items similarly.

They repeat this process twice more, with inspection of each new batch of options happening two at a time (one from earlier batches).

Finally, they arrive back where we started–the original list again. However, now you arrange it according to the urgency for completion.

This technique would be best to use when there are less than 25 total backlog items.

Simple Two-factor Ordering

First, the product owner gives each item a business value from 0 to 5, with higher numbers meaning they are more valuable to the company.

Then, this person takes them over and asks for help categorizing them into two groups: 

1. small enough so it can be completed in less than one day if everyone swarms on it;
2. everything else is too big or uncertain about fitting into the time frame.

The product owner looks at all who fit the first category based on their score. Then, they place them in order and add anything left out.

The product owner should only focus on items in the “small enough” category for this disambiguation work. 

Leave the other items in a near-random order. It helps make prioritization decisions easier when many options have the same business value score. Such a technique works well when there are between 20 and 50 product backlog items.

These techniques require some thought if multiple items within one category share an equal business value score. 

However, it is wise not to worry about them too much. That is, as long as you have classified items under “small” size. The small size typically means fewer than twenty.

Bonus: Click here to understand a product goal and how to define it.

FIFO With Expedited Items

In this technique, the product backlog items get arranged in order of requests.

The only exception is that the product owner can make to move a set number at the start of each sprint.

Also, one can delete items on top if they have been completed or deemed irrelevant. This process works for any size and quantity.

However, all entries must be small enough to complete within one sprint.

Product Backlog Examples

We will take a look at product backlog examples based on goals. 

A product backlog structured around goals is also known as a goal-driven backlog. It focuses on the product goal and breaks it down into sub-features.

The two benefits that you can derive from the goal-driven backlog are:

• Teams can give more time to the business value. They can update and improve the right features in a product.
  
• Since the goals are visible daily, teams feel responsible for working towards them. You can create measurable feedback scores to know if the team is on the right track. 

Sprint Backlog vs. Product Backlog

The sprint backlog is a short-term plan for the team’s workload.

The product backlog is a long-term plan determined by the deliverables that make your products more valuable.

Many people might think that these two tasks subsist on one another. But this isn’t always true because, in reality, they can both be different approaches. 

Though their goals are the same, they often become part of one another.

The product backlog is a container for the essential work that keeps your company active in the market competition. 

It can also frequently change with items added or taken out regularly. It’s generally more prominent than the sprint backlog due to its higher granularity (fewer things broken down below user story levels).

The product owner oversees this list, primarily unassigned tasks.

These unassigned tasks get planned to ensure something new is always coming up so that customers never get bored.

On the other hand, the sprint backlog is a container of the work items the team has committed to doing as part of their next sprint.

It’s an output from the meeting where they decide what work will get done this upcoming week and month, which usually lasts one to four weeks.

One generates the content of these sprints based on the agreed user stories. 

However, if needed, it can also include bugs and refactoring tasks (making code more efficient).

Lastly, software for product managers like Chisel helps teams organize and prioritize their product backlog.

Click here to request a demo session with Chisel.

It is a simple yet powerful tool that makes it easy to collaborate with your team members on the back end of any project or initiative.

With intuitive features like kanban boards, you can easily see what tasks are due next and is it complete or not. 

Best of all, Chisel is free forever! Give it a try.