Photo by Pexels, published under the Creative Commons Zero license

Prioritising the Product Backlog

Published on 18th June 2010

This blog posts explores four useful factors to prioritise the product backlog: value; risk and uncertainty; releasability; and dependencies.

Why Product Backlog Prioritisation Matters

Prioritisation requires us to decide how important an item is. If everything is high priority, then everything is equally important. This means in effect that nothing is a priority, so there is only a slim chance of delivering what the customer really needs.

Prioritisation is part of product backlog grooming, and it directs the team’s work by focusing the team on the most important items. It also freezes the product backlog contents progressively. As items are detailed according to their priority, flexibility is built into the process and allows delaying decisions about the lower priority items, buying you more time to evaluate options, gather feedback from customers, and acquire more knowledge. This ultimately results in better decisions and a better product.

The reminder of this posts explores four useful factors to prioritise the product backlog: value; risk and uncertainty; releasability; and dependencies.


Value

Value is a common prioritisation factor. We certainly want to deliver the most valuable items first. But what makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. You either de-prioritises the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the development team focused. If the item is important for a future version, it will re-emerge.


Risk and Uncertainty

Risk is an intrinsic part of software development; no product can come to life risk-free. Correlated with risk is uncertainty. The more uncertainty there is the riskier the project is. Because risk and uncertainty influence product success, uncertain and risky items should be high priority. This accelerates the generation of relevant knowledge, drives out uncertainty, and reduces risk. For instance, if you are unsure about some aspects of the user interface design, then the relevant design options should be explored and tested by gathering feedback from users. Tackling uncertain, risky items early creates a risk-driven approach that may enforce early failure. Failing early allows you to change course while there is still the opportunity, for example, to modify the user interaction or the architecture and technology selection.


Releasability

Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If you are uncertain about if and how a feature should be implemented, then early releases can answer this question. Being able to release product increments early and frequently should therefore influence the product backlog prioritisation. Each release should provide functionality that is useful to customers and users and that generates the desired feedback. Note that it’s usually not necessary to fully implement a theme; a partial implementation is often sufficient for early releases.


Dependencies

Wether we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even non-functional requirements. And if several teams work together, dependencies between them can influence the prioritisation. Dependencies restrict the freedom to prioritise the product backlog and influence the effort estimates; the item others depend on has to be implemented first. You should therefore try to resolve dependencies whenever possible. If that’s not an option then the dependencies are likely to influence the product backlog prioritisation. Two dependent items may have to be implemented in the same sprint, for example.

Post a Comment or Ask a Question

6 Comments

  • Harri Pendolin says:

    Do you think that market doesn’t matter at all and one can always prioritize the same way building the prioritization scheme bottom up?

    There are new products for a new market (need unknown), new products for “red sea” market (solution unknown) and new releases of products for very different kind of applications. Value may come from learning fast, being different and loveable, fixing bad functionality and adding features, being on time for xmas market etc. Would it be better to understand what really is the VALUE and RISK and communicate that to developers rather than just keep the backlog in minimum and concise?

    • Roman Pichler Roman Pichler says:

      Hi Harri,

      Thank you for your comment. I fully agree that questions like “Which market (segment) should the product address?” and “What makes the product stand out?” should be addressed. This is, however, best done as part of the discovery work IMO, and the answers are best captured in form of a product strategy and product roadmap. To put it differently, I like to work with the following model: Product vision/strategy – product roadmap – product backlog, as I describe my article “A Strategy Map” in more detail.

      Hope this helps!

  • Amy says:

    How do you handle bug fixes with existing products while trying to prioritize work for new product launches ? I have heard people doing things like ; 1 bug fix each sprint or 30% points allocated to fixes and 70% new product enhancements.

  • Jim says:

    What techniques have you found to be most useful in calculating business value up front?

    • Roman Pichler Roman Pichler says:

      Hi Jim,

      I recommend that you define what value the product should create for the business and state its business goals when creating the product strategy. If you want to rank individual features, then I would suggest that you use a cost-benefit analysis (depending on the business goals of your product).

      Does this help?

Leave a Reply to Roman Pichler Cancel reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.