What Is Product Backlog and Who Owns It?

product backlog how why techniques

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 of the new features, changes to existing features, bug fixes, and other 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. 

As previously stated, the items on a product backlog include user stories, changes to existing functionality, and bug fixes.

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

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

When you will work on an item soon, they 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 are continuously changing 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 given project/product development.

When it comes to 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.” 

This position requires keeping track of what items you can remove once they’re completed or need no longer to 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.

points to remember while creating product backlog
Points to remember while creating product backlog

Who Owns Product Backlog?

The product owner owns and makes the final decision 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. 

You should understand 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 be developed.

Talking to other stakeholders can also give them some insight as well – 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. 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 be 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 itself. 

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. 

Both the PO and the scrum team need to work together to give the development team a proper plan on 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 that are should be taken up later, will have fewer details in place 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 the item, and prioritize it accordingly. 

For example, the team’s product backlog items that are 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 only to take the product items that you require for the release. Don’t focus on the other product backlog items. 

This way you save time and are able to concentrate on your priorities. 

How to Estimate Product Backlog?

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

Following are the three estimation methods you can take to make the product backlog estimation.

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, then 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 items. 

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

Once all the cards are stacked on the desk from the pile and all members agree with their positions, you give a number to the product backlog items. This number is given 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 of 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 is based 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 comes in handy when you are unsure of number estimations or are still figuring out the project. 

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

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 first consult and discuss the product backlog items with the product 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 in our ability to deliver on that estimate
  • Effort 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 being 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 certain features. 

MoSCoW stands for must have (necessary), should have (preferable but not necessary) could have (possibly useful 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 difficult to complete the entire project at once.

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 taking a list of various features and initiatives. It quantifies them with value and effort scores to determine their place on the matrix accordingly. 

The value vs. effort prioritization method is an excellent way for organizations to utilize their resources most effectively. Besides that, 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. 

This can either be measured by ROI (return-on-investment) or 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) until finally arriving back where we started–the original list again but now ordered according to priority by 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 that 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 too big or uncertain about fitting into the time frame.

The product owner looks at all those who fit the first category based on their score. Then, they , places 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. 

The other items should be left in a near-random order. This 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.

All of 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 as long as they’re classified under “small” size. The small size typically means fewer than twenty.

FIFO With Expedited Items

In this technique, the product backlog items are 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 also delete items on top if they have been completed or deemed irrelevant. This process works for any size and quantity. However, it requires all entries to be small enough to complete within one sprint period.

Product Backlog Examples

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

A product backlog that is structured around the 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 every day, teams feel responsible to 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 which is determined by the deliverables that make your products more valueable.

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 in approaches. 

Though their goals are the same, often they end up as a 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 larger than the sprint backlog due to its higher level of granularity (fewer things broken down below user story levels).

The product owner oversees this list containing mainly tasks that have not been assigned yet. These unassigned tasks are planned to ensure there is always something new coming up so that customers never get bored.

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

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

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

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

Lastly, Chisel helps teams organize and prioritize their product backlog. 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 whether they have been completed.Best of all, Chisel is free forever! Give it a try here.

Crafting great product requires great tools. Try Chisel today, it's free forever.