4 early signs of a deteriorating product backlog
4 early signs of a deteriorating product backlog
Some signs are staring you in the face. Can you spot them?
The backlog is known to be a source of clarity on future work, but can often be treated as a graveyard of ideas and features that don’t deliver the impact you need. It can’t be too full, nor can it be too empty. It needs to be a healthy enough size for focus and flow.
When I think of the backlog, I can’t stop thinking about a childhood story of Goldilocks and the Three Bears. Goldilocks (Product Manager) finds herself in a foreign home of bears (Technical Teams) looking for food, comfort, and solace. She looks for a place to rest and finds three different beds (backlogs): one too long, one too wide, and one just about right. As a spritely Goldilocks, finding the right sized bed with the right level of comfort can be challenging, but not impossible.
Provided below are some quick indicators you should be wary of as you continue to build features for your customers. Be aware that I have made a few assumptions here:
You are managing your backlog through a tool such as Jira, Trello, etc allowing you to analyse your backlog using Google Sheets at the minimum
You aren’t solving your resource constraints by simply hiring a large number of developers to increase your development capacity
You have a base level understanding or awareness of what Scrum and Kanban are
You have some sort of prioritisation methods already in place. I’ve written a how-to guide on this previously.
1. ‘Issues Created’ significantly exceed ‘Issues Closed.’
You can do anything, but you can’t do everything — David Allen
Using your favourite backlog tools, such as Jira or Trello, you can quickly measure when you are gaining much more work than that you can do by creating a “Created Issues” vs “Resolved Issues” Chart. Track the growth of each daily and set some thresholds for the number of excess issues you are willing to sustain.
🗒 Note: Issues in this context is used synonymously with ‘user stories’
In a defined period (say, a fortnightly sprint or iteration cycle), the number of issues raised probably shouldn’t drastically exceed those that have been closed. If you consistently add more items to your backlog, you will find yourself with much more work than can be sustainably selected for development.
If you have too many stories that are being created, it’s time to cut your backlog to a more sustainable size via backlog grooming, perhaps closer to your ‘lower limit’ specified above; if you can resolve more issues than you create, even better!
🔥 Tip: Overlay the MoSCoW method on your development capacity to see whether you are over or under resourced!
One way to visualise this problem of what you can or cannot work on at any given point of time is using the MoSCoW framework, but comparing it to your available development capacity, which could only be 100% at maximum. If you are trying to work on more issues than your capacity, your technical teams will burn out!
In short, there’s only so much work you can do, relative to what you could do. Let’s take each scenario above:
Scenario 1 depicts a situation where your ‘must-haves’, ‘should-haves’, ‘cold haves’ in total all are within the capacity of your technical team. This state isn’t so bad and is within control: you are always developing some level of value to your customers.
Scenario 2, on the other hand, depicts a situation where your ‘must-haves’ and to a lesser extent, some ‘should haves’ are dominating the majority of your backlog. While you are managing to deliver the necessary items of value to your customers, you are missing out on providing higher satisfying features that may exist in the “should-haves” and “could-haves”.
There’s no perfect number or ratio to recommend here. The more important task is coming to an understanding about whether the items that are in the backlog today are of value to your customers, and whether your existing capacity is enough for you to take on those pieces work.
2. The size of backlog < your team capacity
If you have a team velocity of 30 user stories, and your backlog only has 20 user stories that are ready to be picked, then you have a deficit of 10 user stories that you need to deal with. It’s like not having enough chairs for your dinner guests, with many of your guests awkwardly standing by while the rest of you are sitting! (Musical chairs anyone?)
Some experts believe a healthy backlog should have two sprints-worth of stories ready to be picked for development. This rule is also valid for Kanban-like teams who work on items when and as they can. For example, for a Kanban-like team with a velocity of 20 stories a fortnight, it would make sense that they have somewhere between 20 to 40 stories that they can select for development. Any more than this, in my view, is probably too much noise for the highly focussed product development team.
🗒 Note: My remarks above are assuming that you have roughly equally sized stories in their size of technical complexity.
If you are estimating the effort of each story through story points or similar, this can also add another useful dimension. Simply compare the total ‘story points’ in your backlog to your 2-week (or whatever your iteration cycle is) velocity.
If total Story Points in the backlog is less than Story Points in your ‘Selected-for-Development’ you have a deficit in backlog stories and the risk of having idle teams at the end of an iteration cycle or sprint.
3. High ‘average age’ of open issues
The average age of an open issue is also a telling sign that something has been sitting on a backlog for an extended period, and has not been actioned. Neglect, much?
A simple Jira report for “Average Age of Issues” can be generated for a quick snapshot of whether this trend is improving.
There are a few reasons that can account for a high average age:
You may be too busy working on other issues, which may be much higher in priority than those tickets that are severely ageing.
You may have too many issues in your backlog in general, not allowing any dedicated focus from your technical teams to resolve each issue one-by-one
The issue is simply not essential nor valuable relative to other issues and should be removed from your backlog, perhaps in your backlog grooming exercises.
Whatever the reason, an issue that has been sitting there for, say, more than 90 days, may need to be simply be closed or removed from the backlog. If it is really that important, it can be added to the backlog once more later (but with the right priority next time!)
4. The type of work delivered inconsistent with strategic priorities
Even the highest velocity teams may be developing against the kinds of stories that focus on the wrong metric or user outcome. For example, if your business is heavily focussed on ‘customer acquisition’ as your quarterly objective, it doesn’t make much sense to focus on activities that only retain your existing customers.
A task that may take a little bit more time for a PM is the classification of each issue or story. For for all those resolved in the last 120 days and all those in your backlog, tag them to some strategic themes or categories. For example:
Revenue Growth
User Experience
User Engagement
Knowledge Building
Technical Debt or Compliance
Bug Fixes and Maintenance
Etc!
By classifying your stories by strategic objective or theme, you can create a chart of overtime to see where you have been spending most of your development time and see whether this is in alignment with your business objectives or strategic priorities.
Take a look at the chart above. Do you see any outliers? For me, I see the following:
In weeks 1,5 and 7, the team spent more than 60% of their effort (story points) on Bug Fixes or Compliance. In fact, Week 5 saw almost 80% of the energy spent on Bugs. Why is this the case? Are there stories that are being delivered of low quality, or were specs not addressed correctly upfront?
‘Revenue Growth’ stories were only released in weeks 1 and 2. If the business prioritises more on revenue, then weeks 2 to 8 were not spent wisely.
In week 4, a considerable amount of effort was spent on User Experience, but no other week saw this. If the business wants to have a ‘best in class’ user experience, then the effort shown here may not be the best allocation of resources.
By looking at the areas that you are spending the most time on, you will be in a more informed position to then decide as a group how much of your capacity should be spent on any specific theme.
Final Words
As a PM, you need to have the right attitude and discipline to manage the backlog before it quickly grows out of control. We explored four areas to consider in your weekly or fortnightly checks:
‘Issues Created’ significantly exceed ‘Issues Closed’ — set some thresholds for what is acceptable and what is not. Track weekly.
The size of backlog < your team capacity — ensure you have enough backlog stories available to be picked up to avoid ‘idle hands’
High ‘average age’ of open issues — ensure your issues aren’t too old or neglected. You may have to close old issues to be addressed later on.
The type of work delivered inconsistent with strategic priorities — classify your stories by strategic priorities to ensure you are working on the right kind of work at any given point of time. Review and revise.
By keeping an eye out on a handful of backlog success metrics, you will be able to provide more assurance to your technical teams. Whatever you use to manage your backlog (Jira, Trello, even Google Sheets) Make sure you take the time to classify, analyse, converse and groom.
👋 Let’s be friends! Follow me on Twitter and connect with me on LinkedIn. Don’t forget to follow me here on Medium as well for all things startups, leadership, product, dogs and the mind.