Product Backlog

Product Backlog2017-10-12T22:05:26+00:00

What is the Product Backlog?

The Product Backlog is a summary of the high-level tasks the delivery team and its stakeholders propose should be delivered as part of the Product. As, in Agile, there is a strong bias towards not defining the Product too early – the Product Backlog generally lacks detail. This ensures that effort is not wasted on defining details that:

  • cannot be realistically known at such an early stage.
  • are very likely to change before they are actually delivered.

There is no problem with including extensive detail if it is genuinely known (e.g., legal or regulatory requirements). But even in such cases, there is seldom any need for the Backlog to define that detail – usually it is enough to provide a link to a corporate or public source that provides the extra information.

Click here for more on how Backlogs evolve and mature over the product’s lifetime.

Creating the Product Backlog

Collaborating closely, the Product Owner and other subject-matter experts, business stakeholders and Agile team members analyse the Product Vision (especially the USPs and product description) into distinct elements. These may consist of placeholders that merely remind you of something you need to work on, general concepts, features, epics, themes and (if appropriate) stories.

Many of these items will become work items (stories) that are delivered in later releases and iterations. Some will evolve in unexpected ways, becoming quite new stories, while others will eventually be discarded. Don’t be too concerned with the viability of items in the Product Backlog – many strange ideas have proved to be unexpectedly valuable!

These ideas, etc., are then combined into a catalogue called the Product Backlog.

Managing the Product Backlog

The Product Backlog is never complete. Not only will there be a constant stream of new ideas but it will contain many items that will never be implemented but were included in the Backlog because they seemed like good ideas at the time!

As the highest-level Backlog, the Product Backlog is also the simplest. While Release and Iteration backlogs include implementation details, the Product Backlog is simply a list of work items. It does not matter how detailed Product Backlog items are: a few words is quite enough if that is all you have. And even where a great deal of detail is included, the Product Owner and the items’ stakeholder must understand that it is provisional, and likely to change as experience and circumstances change.

Remember, in Agile change is good.

Even if the content of the Product Backlog items cannot be fully defined at this level, there are ‘management’ details that need to be added. In particular, Product Backlog items need to be:

ClassifiedProduct Backlog items should be classified as one of:

  • User – items that give the users, customers or the organisation as a whole more value, or make users more valuable.
  • Strategic – background items needed to support the User items.
  • Foundational – items needed by the team implement User and Strategic items.
  • Each item in the Product Backlog should be estimated. This gives an early indication of whether it is likely to be worth delivering, or even worth developing further.
  • However, even if the estimate is high, the item should not necessarily be deleted from the Product Backlog. Circumstances may change, causing its value to rise, its cost to fall or it becoming valuable for other reasons. Only if the Product Owner and the product’s other stakeholder agree that it is a bad idea should it be removed altogether.
  • The priority of each item also needs to be defined.
  • At the level of the Product Backlog this indicates how much value the item is expected to generate.

These details should also be treated as provisional, but they are useful for communicating how the Product Vision is being interpreted and for giving a sense of how it may be delivered.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?