New Year’s Resolution: Cleaning Up My Product Backlog

An overgrown backlog. It’s something all growing product companies and agile development teams eventually face. As a product begins taking shape and users begin adopting it, you end up recording more enhancements, bugs, and new functionality. It is a great problem to have, right? That means people are using it and accepting your product. The question is, can you address bugs and expand your product at the same time?

The increase in feedback is the critical moment where a product moves from a Just-In-Time (JIT) Product into a sustainable product. Your users want changes and they want them quicker than your development team can deliver. The once cleaned, groomed, and prioritized backlog quickly turns into a wildly overgrown, chaotic mess of hundreds or even thousands of new features, enhancements, and bugs. Just looking at your backlog makes you want to exhale loudly and drop your face into your hands.

How are you going to clean this mess up? How can you even begin to prioritize this? Where is there time in the day (or even night)?

At 3Pillar, companies have turned to us when their previous development vendors have let the backlog (and sometimes the product itself) turn into the Amazon jungle of stories and bugs. They look to us as a product partner to help them navigate the heavy lifting of overhauling an extensive, disjointed backlog and turning it into a well-oiled machine of product sustainability and growth.

Timed Release CycleIn these instances, we take a proven, four-step approach to pruning an overgrown backlog. Similar to how products should be iteratively developed, so too should overgrown backlogs be iteratively shorn.

Step 1: Identify a Timed Release Cycle

You’ll never get anywhere on time if you don’t know when you’re supposed to be there. Create a high level, feature focused roadmap with multiple releases. Depending on the complexity of your product, a release could contain one or many sprints. If your backlog is overgrown, let’s assume that you will need numerous releases before the backlog is sufficiently pruned. This will force you to see what is most critical for your end users and to identify your priorities. Furthermore, it provides you and your development team with a more holistic product vision for the future.

Step 2: Create Release Backlogs

From the roadmap you created in step 1, identify all stories in the overgrown backlog that pertain to these features for the first release. During that process, you should be sure to eliminate all stories that are out-of-date, duplicates, or have already been addressed.

Once you have identified backlog stories for the first release, perform a gap analysis of what user stories/bugs are missing to complete the release. Write new stories when necessary, then reprioritize those stories/bugs into your initial release backlog. Now you have a baseline release backlog where you can now effectively perform sprint planning.

You may have to break functionality (turn the story into an epic) over a few sprints to complete it, but all user stories should be able to be accomplished in your release. If you cannot complete the functionality within a given release, then reassess your stories and what functionality you can deliver for that release. Chances are you will have to descope. If, for example, you tried to take on all 87 stories in the backlog below in one sprint, you will either end up with code that is a complete mess, a development team that despises you, or both.

Product Backlog Screenshot

The sprint planning for the first release will provide you with a guideline of what can be accomplished in a release (i.e., enable you to measure your velocity). This will help readdress your roadmap for subsequent releases to be more accurate based on resources and constraints.

Step 3: Icebox Your Old Backlog

After you have created your roadmap and release backlog for the first release, you can now icebox your previous backlog. Tempting as it may be, this does not mean you can close out all the tickets or to delete them all. This simply means to rename the previous backlog to, “Ice-boxed Backlog” or something else to that effect, so that team members will not make the mistake of adding new stories/bugs there.

This backlog will still be leveraged when creating new release backlogs down the road to find older stories pertaining to the features (as performed in step 2).

Step 4: Create a New Backlog From Release Backlogs

After you have successfully completed your first release (congratulations!), you will likely have a few items that weren’t fully completed.

No problem! That’s the nature of agile development. These items have just become the first seeds to your overall product backlog. Create a new backlog, label it “Product Backlog (New),” and perform steps 1- 3 again.

You should always be creating new stories/bugs as they come along and adding them to the new product backlog. This step is really just to explain what to do when you have leftover items from your release backlog).

Iterate vs. Obliterate

By breaking down, through iterations, the pruning of the original backlog into smaller, more manageable releases, you allow your development team to address the most pressing items first. This makes business owners happy, and at the same time, your team does not feel like they have to tackle everything all at once.

The process allows you as a product manager to adapt to ever-changing business and technological priorities, and it allows for a directional overhaul without the need for major overhead.

The main goal here is to focus on the overall high-level picture (roadmap) and then to focus on the immediate future (your next release). Too many times, products lose sight of what they are and what they want to be because too much emphasis is being placed on roadmaps set too far in the future (3+ years).

Remember, products are not projects. They are living entities that are never done. They need attention like anything else that grows in life organically.

Brian Oh

Brian Oh

Product Manager

Brian Oh is a Product Manager at 3Pillar Global. He has successfully launched several products ranging from large scale SaaS products to quick turnaround iOS and Android applications. Prior to joining 3Pillar Global, Brian was heavily involved in the Federal Government sector with Booz Allen Hamilton, SAIC, CGI Federal, and Ernst & Young for the Department of Homeland Security, Department of Defense, Administrative Offices of the US Courts, and Veteran Affairs, respectively.

Leave a Reply

Related Posts

Building a Microservice Architecture with Spring Boot and Do... This is the first post in what will be a 4-part series on building a microservice architecture with Spring Boot & Docker. This post will provide a...
Building a Microservice Architecture with Spring Boot and Do... Part II: Getting Set-Up and Started Introduction and Tools In this part, we'll get to work on building out the solution discussed in Part I. I'm goi...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Innovation Wars, with Scott Bales Scott Bales joins us on this episode of The Innovation Engine to dive into the concept of "innovation wars." Among the topics we'll discuss are what c...


Sign up today to receive our monthly product development tips newsletter.