If you followed Parts 1 and 2 of our Taming the Backlog series, you know that the characteristics of a healthy product backlog support the flow of value at a sustainable pace. By focusing on having a healthy backlog, you can ensure minimal time is wasted on items that aren’t likely to be worked on soon, or ever. Plus, the risk of delivering the wrong solution is reduced significantly. Efforts to keep a team’s active backlog healthy, trimmed to the right size, AND objectively prioritized are critical for ongoing, sustainable value delivery. 

Finding the Right Size

What should your organization do with hundreds to thousands of backlog items that have built up over time? If you’re comfortable with it, the simplest approach is to delete anything that’s not likely to be worked on soon or was completed long ago. Do keep in mind that deleting items may impact any historical reporting based on backlog data–a small price to pay for the benefits. 

If deleting items from your backlog makes you, the team, or your organization uncomfortable, there are plenty of other ways to “remove” items from your active product backlog. 

  • Create a new backlog. Leave the current backlog as an archive and start fresh. Move or copy existing backlog items to the new backlog. Less is more to start. Leave room for new requests to come in, because they always do. 
  • Export a backup, then delete inactive items. Keeping a backup of your product backlog from time to time is a good idea in general. Deleting the inactive items from your backlog becomes liberating, especially knowing you have a backup to go to if necessary. 
  • Use versions. Many workflow management systems for software teams support versions, which allow you to organize backlog items for a given release or product version. Generic versions–such as Backburner, Fridge, and Freezer–can also be useful.   
  • Use labels or tags. You can establish a labeling or tagging standard to identify items considered to be in the active backlog or not. This will allow you or the Product Owner to query the items in the active backlog in a virtual view. 

Taking one or many of the steps above can help you reach the target you’ve set for total number of backlog items. From there, your next challenge is proper prioritization.  

Prioritizing the Product Backlog

Prioritizing a backlog can easily induce analysis paralysis in Product Owners.  With a steady stream of new requests coming in that need to be evaluated, how do you prioritize (and re-prioritize) what your team works on? Maybe you’re caught between paying back tech debt that is slowing down value delivery, or delivering a feature requested by your most important stakeholder. Perhaps you and your team want to innovate, but the level of production support required keeps leaving you with no time for it. The fact is, there needs to be balance.   

The path to backlog balance is not complicated. It does require you to gather data and then have some candid conversations with your stakeholders. The first step is to understand what percentage of time the team currently spends working on the following: 

  • Product Support – supporting what you built 
  • New Features – building to generate revenue 
  • Technical Debt – cutting corners to deliver faster (note: this can come with high costs) 
  • Innovation and Training – creating new opportunities, saving money, and strengthening the workforce 

With team allocation data in hand, you now have the context you need to make prioritization visible for your internal customers. You can have conversations with them about how time is currently invested and get their input on the desired percentages of time ideally invested in each type of work. Together, you can outline a plan to get to the ideal balance.   

Clear expectations will be set, and the Product Owner will have an objective framework to prioritize within. Yes, there will be exceptions. Product support may spike. Unsupported hardware and software must be upgraded by a certain date. When the exceptions become too frequent, it is time to discuss recalibrating the ideal percentages to get balanced again. 

There are generally more work requests than time available, which can create stress for a team. That’s why objective prioritization is critical. You can take the emotion and anxiety out of the backlog prioritization process. The key is making the time invested in each type of work visible and having data-driven conversations. Keeping the product backlog balanced also gives the team confidence that they’re working on the expected work at the right time, allowing them to focus on the work itself. 

Ready to Tame Your Backlog?

The backlog management concepts and processes presented in this series can be applied for a single team working from a single product backlog, and at scale. It’s not uncommon for teams in large enterprises to pull work from multiple product backlogs shared by multiple other teams, each with a team backlog that they plan and manage their iterations in.      

If there are two constants across software development ecosystems and frameworks, they are teams and work. Teams need a way to manage their work, and that happens through their backlog. Execution on strategy, outcomes, and experiences happens through the backlog.  A good backlog management process will yield data that can be used to estimate future delivery timing, with improved accuracy over time for persistent teams. Backlogs, at their core, connect the dots to track the investments a company is making in products and IT through people and technology. 

So, we end where we started: the product backlog serves many purposes. It is the single, most important artifact for Agile teams. It’s so important that Polaris Solutions is offering to do a two-hour working session with you. We’ll review your backlogs and discuss opportunities to improve the value they provide your team and organization. Contact a 3Cloud team member today to get started.