Product Backlog

Hi, welcome to my first article for the AMI blog. My topic for this post is the Product Backlog.

When speaking about any Scrum topic, it's important to go directly to the most updated version of the Scrum Guide and read what it has to say about it:

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

And who maintains it or completes it?

The Product Owner is responsible for the Product Backlog, including its content, availability and ordering.

Reading further:

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact.

You can probably agree that if you are developing a product with your team, you must have a Product Backlog. It is the backbone of your work, as it helps, among other things, to express the value that will be added to the product. And it provides transparency about what is happening to the product, team, stakeholders and the whole organization.

Also, we can find in the Scrum Guide that:

A Product Backlog is never complete. […] The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive and useful. If a product exists, its Product Backlog also exists.

This makes me think that the Product Backlog is the Product Owner’s best friend. And of course, the Product Owner should be able to count on the help of the Development Team to better understand the work to do so that he or she has more knowledge to manage the Product Backlog. To achieve this goal, refinement should be done to the Product Backlog. And the Product Backlog refinement meetings are where this magic happens:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

For information about how refinement is done in Scrum MF, click here.

As time goes by, many ideas and features will be added to the Product Backlog. And if it ends up getting too big with an overwhelming number of items, some problems may arise: 

  • Time is wasted looking for items
  • Ordering and prioritization will be more difficult and will take longer
  • Duplicate items may appear as the original item could not be found, but is still somewhere in the Backlog

If this happens, remember that the Product Owner is not alone when dealing with the Product Backlog. Scrum Masters are expected to help the Product Owners in several ways, which include:

  • Finding techniques for effective Product Backlog management
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value

 As a Scrum Master, I can recommend to any Product Owner with a messy Product Backlog a few approaches to keep it manageable, clear and of a reasonable size:

  • Delete things you are certain you will never do. Those are probably old items that may be no longer needed or obsolete. If you don’t think you’ll realistically ever do them, just remove them from the Product Backlog.
  • Regularly revisit, review and clean the Product Backlog so that it won't grow out of hand.

If you are concerned that you will end up with a Product Backlog without any items, trust me when I tell you that this won’t be an issue at all. New ideas usually appear faster than they can be developed by the Development Team. That is the magic of Agile.

Thank you for reading, and remember that the AMI team is always here to support Agile and the Scrum MF framework. We are open to all concerns, so don't hesitate to contact us. And don’t forget—keep calm and be Agile.

You may also like:

A Product Owner’s To Do List in Perfect Development

Our last article covered the Perfect Development Agenda. Now we will start with the first To Do list: the Product Owner’s. There are four To…

Deviations from Optimal Planning – Backlog Not Ready

We spoke about Optimal Planning, so now let’s dig into the deviations from it. The first one is if the Backlog is not ready. If…

Estimate and Select from the Top of the Product Backlog

You have learned how to “play” Planning Poker and what Story Points are. Let’s have a look at the next three rules. If Developers determine…