Product Backlogs should be relatively short. The longer they get, the harder they are to use effectively. In this blog post, I talk about why a large Product Backlog is bad news and what you can do to fix it.

I worked with a customer once whose Product Backlog has 45,000 items in it. To put the ridiculousness of this in perspective, even if the customer used all of their Scrum team capacity to address the Product Backlog AND the Product Backlog didn’t have anything added to it, it would still take 20 years to complete the content of the Product Backlog. Is your Product Backlog hundreds upon hundreds of items long? How did it get that way and, honestly, should it be that long? We’ll answer those questions, and more, in this post.

The Product Backlog is defined in the Scrum Guide as

an emergent, ordered list of what is needed to improve the product.

A Product Backlog emerges – which means that there’s no moment in time when the Product Backlog should ever be considered complete or “frozen.” Product Backlog Items are created as they are identified – many at the beginning of a development, but just as many during the development effort itself

1. as the stakeholders and the team learn more about the product,
2. as larger backlog items are sliced into smaller backlog items,
3. as the market conditions change,
4. as new requirements are identified,
5. as technological conditions change.

In other words, there’s a lot of reasons why new product backlog items are constantly being created. Clearly, however, we can generate new product backlog items far faster than our Scrum teams can complete them. As a result, Product Backlogs tend to get longer and longer, until they are simply too big.

Yes, a Product Backlog can get too big. Consider the example I opened the post with – what good is a Product Backlog that would take 20 years to complete? Would any stakeholder or customer be willing to sit around, waiting 20 years for a feature?

What about just 5 years?

3 years?

Realistically, Product Backlogs should have no more content in them than the assign Scrum teams could build in a timeframe reasonable for the product being built. In today’s world, that’s no more than 10-12 months. No stakeholder, customer, or user will sit around waiting more than 1 year for a feature or enhancement.

So, What Do I Do With an Out of Control Product Backlog?

If your Product Backlog has gotten too long, it’s time to trim it. Start by finding backlog items that have been in your Product Backlog for more than 10 months. Anything older than about 10 months should be deleted or, at the very least, archived. If you can’t delete, create a second Product Backlog and move the older items to that Product Backlog. You can use that as the “Archive” from now on.

Be brutal. Think of trimming rose bushes. If you don’t have a stakeholder, customer, or user climbing up your back to bring your attention to a backlog item, they don’t really need it that badly. Get rid of it.

How Do I Keep My Product Backlog Under Control?

In the most recent version of the Scrum Guide, the “Product Goal” was created. According to the Scrum Guide:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

The Product Goal describes a future state of the product; we want to achieve this state to bring us closer to the Product Vision. Once a Product Goal is achieved, a new one can take its place to move us even closer to the Product Vision.

What this means for us is this: your Product Backlog should be filled ONLY those backlog items that may help us achieve the current Product Goal. As we get closer to achieving the current Product Goal, a new Product Goal is proposed and the Product Backlog will be extended to incorporate the backlog items necessary to achieve the new Product Goal.

For example, let’s say I’m dog crazy (not a stretch) and I don’t like seeing my pups laying around all day while I work. I set out to solve the problem with a vision:

All dogs are having fun and getting exercise, even when I have to work.

I discuss my vision with friends and colleagues and we believe that a product that connects dog walkers and dog owners (think “Uber for Dogs”) would solve the problem.

As the Product Owner, I write our first Product Goal:

By April 30 of next year, we will have 500 registered dog walkers, 300 registered dog owners, scheduling 75 walks per day.

With that Product Goal in mind, I gather a group of stakeholders, potential customers and user, and maybe an application developer or two and we determine the initial content of the Product Backlog. We come up with the following list:

1. Register dog walkers
2. Register dog owners
3. Schedule a walk

That’s what we start with to accomplish our Product Goal. Then I gather a team of developers to build the product and, with the stakeholders, customers, and user from before, we begin refining the “top” of the Product Backlog. This is the result:

1. Register dog walkers slices into:
   • Collect dog walker basic info (name, email, ssn, birth date)
   • Do a background check
   • If they fail, let them know and tell them why.
   • If they pass, collect walking preferences (when are they available, where can they walk dogs, how many dogs, any breed restrictions)
   • Collect bank/PayPal information to pay the walker.
2. Register dog owners
3. Schedule a walk

As the developers dig deeper and begin building the backlog items, the technical details come out – that’s why we don’t try to write a huge Product Backlog – we don’t need to. The details come out when we’re ready for them.

As we get closer and closer to the Product Goal, the Product Backlog stays relatively short (there will likely be backlog items that we write but never build). By the time the Product Goal is achieved, the Product Owner has written a new one and again, with help, writes new backlog items to achieve the new goal. Anything left in the Product Backlog when the first goal is achieved can be archived or deleted.

If you follow this simple approach, you’ll keep your Product Backlog short, under control, and valuable. Try it and let us know what you think in the comments below!