Four Steps to Keep Your Product Backlog Small and Manageable

Four Steps to Keep Your Product Backlog Small and Manageable

You should always strive to keep your product backlog small and manageable. With too many items on the product backlog, three problems arise:

First, it is harder to work with an excessively large product backlog. Time will be lost looking for items. (“I know it’s in here somewhere.”) Prioritizing the backlog will take longer. Duplicate items will appear as it will be easier to add an item “just in case” rather than be sure it’s not already listed.

Second, the development team barely notices any progress they make. A team that finishes 10 of 50 product backlog items can sense that they’ve made progress. A team that finishes the same 10 but out of 1,000 items will not feel the same sense of accomplishment. They will begin to wonder if it would matter if they had only gotten 9 done instead.

Third, someone spent valuable time creating all those product backlog items. Having visibility into the future a bit is great. How far depends on a lot of factors but many backlogs attempt to provide insight too far into their products’ futures.

Because these problems of an overly large product backlog can be so harmful, I’d like to present four things you can do to keep your product backlog to a more manageable size.

1. Delete Things You’ll Never Do

The first thing you should do to keep your product backlog small and manageable is delete items you’ll never do.

I fully acknowledge this can be hard to do. For years, I worried that if I deleted things, I’d walk into the office one day and my team would say, “We’re caught up. What next?” and I wouldn’t have an answer because I’d deleted all the long-term items.

I was finally able to let this fear go by realizing: I can come up with new ideas faster than they can develop them.

I encourage being fairly ruthless in purging items from your product backlog. If you don’t think you’ll realistically ever do it, just get rid of it.

Otherwise, a product backlog just accumulates more and more over time. That task of “learn to dance the Macarena” that’s been on my personal backlog since 1995 just got deleted. By this point, it’s not happening.

2. Keep Items You Aren’t Ready for Off the Product Backlog

For a handful of years, I’ve had a lot of success keeping product backlogs manageable by maintaining a separate list of items that the product owner wants but isn’t truly ready to have the team work on.

I refer to this as a holding tank. A holding tank allows me to restrict the product backlog to items that are desired immediately. The holding tank contains items that are either not quite ready or may not be needed after all.

I think of the difference like this: The product backlog contains all the things that the product owner would pay the team to work overtime tonight on and deliver.

There’s no chance a team can complete them all tonight. I just encourage thinking of it that way because these are the items that the product owner knows are needed and would be willing to pay for right now.

The holding tank contains things the product owner probably wants but either hasn’t thought through in enough detail or may decide aren’t needed after all.

I’ve found this approach extremely helpful because it leads to an immediate reduction in the size of the product backlog as items are moved from it and into another temporary holding place.

Metaphorically, you can think of the difference between a product backlog and holding tank as simply a line drawn below some item in the product backlog. Above that line are the items the product owner would pay the team tonight to deliver; below it are items that could change or aren’t well understood yet.

More practically, what I’ll do in whatever tool I’m using is create a second project, name it the holding tank, and move items to it from the product backlog.

Doing this allows the team to focus on the much smaller set of items that form their product backlog.

3. Periodically Review the Product Backlog

The third step in keeping your product backlog to a reasonable size is to institute a regular review process. Nothing fancy is needed here. It can be as simple as the product owner reviewing the product backlog and deleting or moving items as described above. I think doing this quarterly is best.

4. Don’t Add Things Unless You Plan to Do Them Fairly Soon

Finally, if you want to keep your product backlog small and manageable, you need to be disciplined in not adding items to the backlog unless you fully intend to do them.

Most product backlogs become unwieldy because it was easier for a product owner to say, “I’ll put it on the product backlog” than to tell someone their feature would never see the light of day.

To keep a product backlog in good shape, product owners need to learn to say no or not now. I’ve found that the other tips in this article help them in doing that.

What’s Your Experience?

Have you worked with an unwieldy product backlog? Do you have any additional tips for keeping a product backlog small and manageable? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.

If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.

Thomas K.

Senior Program Director / Innovation Executive - Global PMO, CX, Digital & Loyalty Program Transformation, Online Gaming at JPC Ltd.

5 年

Excellent advice Mike. Partnership is a critical success factor to controlling volume as well. Working collaboratively hand in glove with the Product Owner to manage expectations and pace is essential.

回复
Todd Kovalsky

Program & Product Manager. Delivering enterprise solutions to transform business using AI and analytics.

5 年

Once had a backlog about 1,500 items. Half dated back 8+ years. Needless to say, those were the first to get closed.

回复
Javier Molina

Senior SWE @ Grafana | Transforming Ideas Into Solutions

5 年

This is really disruptive Ivan Rodriguez Salguero

回复
Sahana KS

Agile Coach/Scrum Master/Program Manager/Project Manager @TCS | PSM I | PSM II | SAFe Agilist 5.1

5 年

Good one. Makes sense.

回复
Mike Spieker

Ondernemer @ De Kompanen & Yellops

5 年

Katja Bouwmeester interessant irt jouw werk!

回复

要查看或添加评论,请登录

Mike Cohn的更多文章

  • You Don't Need a Complicated Story Hierarchy

    You Don't Need a Complicated Story Hierarchy

    Consultants and tool vendors seem to have a penchant for making things complicated. It seems the more complicated we…

    7 条评论
  • Agile Teams Need to Balance Specialists and Generalists

    Agile Teams Need to Balance Specialists and Generalists

    There's a mistaken belief that to be agile, every team member must become a generalist. What I find surprising about…

    28 条评论
  • Product Owners: Quick Action Isn’t Always the Right Course

    Product Owners: Quick Action Isn’t Always the Right Course

    I’ve been doing a back-to-basics tip series, exclusively for my subscribers. This past month’s weekly tip focus has…

    14 条评论
  • With Agile, It’s Not What You Do. It’s What You Do Next.

    With Agile, It’s Not What You Do. It’s What You Do Next.

    I’ve been writing a series of tips about product owners, exclusively for my subscribers. It got me thinking about the…

    6 条评论
  • What Happens When During a Sprint

    What Happens When During a Sprint

    Successful Scrum implementations involve a handful of important sprint events (also called sprint meetings or sprint…

    2 条评论
  • What Are Agile Story Points?

    What Are Agile Story Points?

    Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully…

    14 条评论
  • Don’t Equate Story Points to Hours

    Don’t Equate Story Points to Hours

    I’m a huge proponent of estimating in story points. (You can get a full overview of how to use story points from…

    49 条评论
  • Epics, Features and User Stories

    Epics, Features and User Stories

    I’ve been getting more and more emails lately from people asking, “What is an epic, a feature and a user story in…

    6 条评论
  • Nine Agile Halloween Costumes for Scrum Teams

    Nine Agile Halloween Costumes for Scrum Teams

    It’s time to start thinking about an appropriate costume you can wear to the many agile-themed Halloween parties you’ll…

    4 条评论
  • 5 Ways to Split User Stories: The SPIDR Method

    5 Ways to Split User Stories: The SPIDR Method

    Splitting user stories. It’s something I get asked about every day.

    45 条评论

社区洞察

其他会员也浏览了