Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *


Tell us why you're considering making a switch:


4 Most Common Product Backlog Mistakes

30 Mar 2018

Facepalm man with title

One of the three Scrum Artifacts, the Product Backlog represents a single ordered list of everything that is needed for a product, including but not limited to:

  • Features
  • Functions
  • Requirements
  • Fixes
  • Enhancements

The Product Owner is responsible for the Product Backlog, including the content, ordering and availability. The Product Backlog is a dynamic artifact that changes over time and helps the team(s) build an appropriate, competitive and useful product.


If there are more Scrum Teams working on a single product, they still use the one Product Backlog from which they pull Product Backlog Items to their individual Sprint Backlogs during Spring Planning.

Due to the fact that the Product Backlog plays a vital role in how the product is developed, it is crucial that the Product Owner and all other members of the team understand how to manage and contribute to it.

Unfortunately, this doesn’t always go as planned as there are many mistakes that can be made, both intentionally and inadvertently. Today, we will be looking at the most common and impactful of these mistakes, as well as at how they can be best avoided.


Not Considering a Product Roadmap

Poor Formulation of Product Backlog Items

Poor Product Backlog Ordering

Lackluster Product Backlog Refinement

1. Not Considering a Product Roadmap

Depending on the nature and the scope of the product and the upcoming work to be done on it, a product roadmap can be the perfect weapon to add to the arsenal. It is a strategic, tool which shows how the product is expected to grow over time and across a number of major releases.

A product roadmap is a high-level tool which shows initiatives and steps that will be undertaken, together with a timeline which indicates how the product will grow in phases. It provides the context for everyone involved, including all internal and external stakeholders.

In the ideal scenario, the roadmap will facilitate collaboration, reinforce the sense of continuity, increase adaptability to marketplace conditions and coordinate all internal stakeholder efforts.

In addition to this, a product roadmap will provide the perfect starting point from which the product backlog will be derived. The Product Backlog will further identify and refine epics, user stories and other types of Product Backlog Items that a Scrum Team may use. This approach can also help keep the backlog focused and not overextending into the future.

Of course, the Product Backlog and its development over time will allow easy modifications to the product roadmap so that it better corresponds to the product realities.

It should be pointed out, however, that not all products warrant a product roadmap and that sometimes there will be too many unknowns for a realistic roadmap to be formulated.

2. Poor Formulation of Product Backlog Items

One of the core practices in managing a Product Backlog is the proper formulation of Product Backlog Items. The official Scrum Guide does not prescribe what can constitute a PBI and Scrum teams may use anything that works for them as PBIs - user stories, specifications and requirements, bugs, refactoring sessions, timeboxed research and knowledge-related tasks, etc.

And while PBIs’ nature is not prescribed, the Scrum Guide clearly states that all PBIs need to have the following qualities:

  • Description - what the PBI’s goal is
  • Value - the business value of a PBI (determined by the Product Owner)
  • Order - the level of priority for a PBI (determined by the Product Owner)
  • Estimate - estimation of the relative effort needed to complete the PBI (estimation done by the Development Team)

It seems like an easy enough task - describe the PBI, determine its value, ask the dev team for the estimation and decide on the priority of the PBI. The only problem is that there is a wide variety of mistakes a Product Owner can make when doing these (don’t worry, we won’t go through all of them, just a few).

Product backlog

For example, a PBI may not be described clearly enough or vice versa, be described in far too much detail, becoming unclear due to too much input. Larger PBIs might warrant further breaking down into smaller and smaller PBIs. Or, the Product Owner might decide to describe to minutiae all PBIs too many sprints in advance, wasting too much time and often leading to rewriting them when new circumstances arise. The Product Owner might even decide to disregard or override the estimates provided by the Team, thus completely missing the point of the whole concept. Estimating everything for Sprints that are too far in the future is also a common mistake.

The matter of prioritization presents even more potential pitfalls and it really warrants its own section.

3. Poor Product Backlog Ordering

Ordering the Product Backlog is an essential part of the product owner’s responsibilities as proper ordering of PBIs to be worked on ensures the product will grow in a sensible manner, that the maximum amount of value will be added with each iteration and that the team(s) will not have to constantly track back to do something that should have been done iterations ago.


There is a number of different formal approaches to Product Backlog ordering, including MoSCoW, business value-based, technology risk-based, walking skeleton, validated learning and Kano Model, just to name a few.

One common problem with ordering the Product Backlog is deciding on the priority of fixing bugs and refactoring work and how to weigh them against the more traditional user stories that add functionalities to the product. Some Product Owners even keep a separate bug backlog for visibility purposes and this makes it even more difficult to coordinate everything across two different backlogs.

Another common problem occurs when the Product Owner does not consult and collaborate on the product backlog with the Development Team. The Development Team provides invaluable insights that can, for example, help the product owner better understand the dependencies and different types of risks. Product Owners ignore Dev Team input at their own peril.

In the majority of cases, the Product Owner will find that ordering the Product Backlog is a fantastically sensitive matter, requiring the right mix of the different aforementioned approaches and further complicated by input from external stakeholders. It should also be pointed out that not all products are the same and that different approach might be taken for different products and marketplace circumstances, even by the same Product Owner.

4. Lackluster Product Backlog Refinement

A Product Backlog is a dynamic, living artifact and while pretty much all Scrum Teams and Product Owners understand the need to continuously and actively manage it, the fact remains that a lot can go wrong when performing Product Backlog refinement.

In some Scrum teams, for example, Product Backlog refinement is performed almost exclusively by the Product Owner with little or no input from other members of the team. This is probably the biggest refinement mistake that can be made. The Development Team should always have a say in this process, sharing their knowledge, experience and understanding of the development process. In addition to this, a collaborative refinement process also helps the team better understand the backlog and makes them more engaged.

Some Product Owners may feel apprehensive about “taking the knife” to the backlog and deleting Product Backlog Items or even archiving them. In some situations, doing exactly this is the right thing to do. Due to new circumstances, for certain PBIs, the chances of ever delivering value and actually being worked on drop to zero and deleting such PBIs is the only way from keeping the backlog from becoming bloated and too cluttered.

We should also mention the question of when to do product backlog refinement and how much time it should take. In most cases, one refinement session per a Scrum sprint is enough.

Some teams choose to hold special backlog refinement meetings and this is a good idea because it ensures it happens regularly and it provides another opportunity for the entire Scrum Team to discuss the important issues.


The ideal situation is one where backlog refinement becomes a part of everyday communication within the team and between the team and the Product Owner (especially when the PO is co-located and available). This “organic” backlog refinement adds value by encouraging conversations which should always be at the core of the Scrum process. For more experienced teams that perfect this organic backlog refinement, formal meetings can even become obsolete.

Closing Word

It goes without saying that this article doesn’t cover all of the mistakes that can prevent a great Product Backlog from being created and managed. However, we believe it is a good start that will get your mind working in the right direction and (hopefully) inspire you to have some meaningful conversations.


Build your own Product Backlog in our Scrum software.



Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.