Facing an overwhelming backlog is a challenge that anyone in product roles or agile teams will face at some point in their career. It was a common enough challenge to be the subject of an entire discussion at a meet-up I went to recently. Many folks there, myself included, had joined companies or teams as product managers only to inherit enormous existing backlogs containing potentially years of development work. If you've been in this situation you'll know that it's a struggle to manage the expectations of too many stakeholders, each of whom wanting you to prioritise their particular items at the expense of others.
I believe that a large part of the problem is when we view as one backlog, something that is far better viewed as two...
Easy to grow, hard to deliver
Sometimes practices are adopted by teams because they are the right approach for the context that the team is operating in. At other times we do things simply because everyone does it, rather than through a clear understanding of what we're trying to achieve. Product backlogs can suffer from this problem - they're an assumed part of modern development and it's all too easy to fall into the trap of growing a significant backlog without knowing exactly what you're going to do with the items in it.
- Adding something to the backlog provides a short term fix for the product manager to ease pressure from stakeholders.
- Having something added is perceived by those stakeholders as the first step to getting it delivered
- Items are rarely if ever removed to avoid upsetting anyone
- The backlog grows to be so unwieldy that overlap and duplication between items is commonplace
- The vast majority of the backlog remains perpetually undelivered. Instead what happens is that items are added to and delivered from the top of the list. A small and fluid layer of items flows in and out of the list while the remainder stagnates into an irrelevant morass.
This situation isn't just frustrating - it can impact you commercially. A few years ago I worked on a project to create a new loyalty programme for a large corporate client based on a successful programme for a sister brand (that was on too weak a tech stack to reuse). At the point I was asked to take it on the account team had agreed that literally every feature from the existing programme would be recreated. This was a system that had evolved over years, with some of the features suffering very low or zero use. Even delivering the core, high value capabilities was a huge task. Once that was achieved both the customer and we found that we were prioritising other higher value items over the ones in the backlog. This should have put us in a really strong position to be shown to be delivering a high value capability in an agile way, but instead the weight of existing backlog meant we were always in a weak negotiating position.
What I see as the root of the issue with situations like this is that a single approach is being used for two very different needs, and the first step in tackling an overwhelming backlog is to recognise what these are.
Need 1 - Tracking items through development
The first purpose of a backlog is to track items through development. In my experience it helps to keep this as short as possible - to serve its purpose it's only necessary to include things here that are committed for imminent development.
Keeping this list to only the items that are in scope for research or development work is essential to maintain a focus on what the team are working on and I typically just maintain the items pertinent to the current release period (e.g. quarter year) in this list. It also helps to take the pressure off the PO or PM to be constantly curating a massive list of items and track which ones are ready for development. It's far less effort to keep a tidy window box than maintain a landscape garden.
Need 2 - The ideas list
The second list has a completely different purpose which is to capture potential future developments. It's a place for capturing feedback, insights and ideas on what might be valuable to add to the software in the future. In this list we want to connect related feedback together to allow an informed comparison to prioritise against other potential developments. Any information that helps to understand the value of the item, including the evidence to support our confidence in the value of the item and any information on feasibility and effort.
What we're not trying to do here is prep things for development. If we accept the fact that there will be a decision point on progressing something into the development backlog then we can be much freer in how information is captured in this list. It's fine to reference notes, early sketches, photos of whiteboards as well as customer quotes on their needs without worrying that these may inadvertently picked up and translated literally into product features.
When adding items to the ideas list I make it clear that these contribute to prioritisation of future work but there's no certainty that they will get developed. This message needs to persist right out to all roles that communicate to customers, so that they don't give the impression that accepting a 'feature request' means anything other than extra information to help in prioritisation.
How to do it
Once we appreciate the fundamental differences between our lists then it becomes clearer that we need to manage these in different ways. For tracking development having a physical display in the room during discussions, on either a physical board or on a TV, is important to give visibility and allow collaboration between roles. For capturing feature requests and ideas the need for collating different sources of feedback and data to feed prioritisation decisions requires very different capabilities more focussed on cross-referencing, indexing and ranking.
I've used a few approaches to managing these separate concerns.
- Jira has a really flexible organisational structure around boards and custom types. When working with Jira an approach I have used one board to gather 'ideas' as a custom ticket type, and then translate these into Epics when I want to commit them to the development team backlog.
- Microsoft Azure Devops (formerly TFS) has a hierarchical structure of teams, areas and iterations. I have managed longer term activities using a Product 'team' looking at a top level iteration based on epic items, pushing more detailed items into development teams based on more granular iterations when they are committed for development.
- The best way I've found, however, is simply to use two different products, one designed for taking development work and one specifically created for capturing roadmap items and gathering feedback requests. I currently use ProductBoard for capturing customer insights and planning strategic roadmap, with Azure Devops used to track work through the teams. The tool has a nice capability of capturing customer 'insights' via email or from our support system and linking these to potential features (I have no connection to this tool and don't recommend it over others serving a similar need).
I typically don't capture supporting research and high levels of detail in a tracking tool. I prefer to persist detailed research in a wiki and add links to the relevant items, as wikis are easier to organise and find related information that can apply to multiple potential developments.
Names are important
Splitting a backlog isn't just a way to improve organisation. Changing the way that you communicate around feature requests is an important first step to taking ownership of the product direction. When ideas or feedback are captured into a 'backlog', that carries an implication - the name backlog means 'an accumulation of uncompleted work'. This is an unfortunate terminology that implies development teams are permanently lagging behind where they should be because in an ideal world every item should have been delivered already. Any list of potential developments and feature requests is not a product 'backlog' because the future is uncertain and just listing ideas should lead to an assumption that they will get done.
While we're on the subject a huge list of desired capabilities is not a 'roadmap' either. The very existence of a large backlog that a product team is expected to deliver inhibits strategic planning so much that it would more accurately be described as an 'anti-roadmap'. What it is is a catalogue of potential opportunities, and the Product role should be focused on selecting from these in a way that provide the greatest value, irrespective of whether they've were identified years ago or yesterday.
So if you are in the situation where you are struggling with an overwhelming backlog, the approach that I would recommend is
- Create a second 'ideas list'
- Move anything not committed for imminent development into it
- Establish some clear rules around accepting feature requests
- Communicate the basis that you will prioritise items into development
Then hopefully you'll be able to stop worrying about how to get through your enormous backlog, and start being optimistic about the great list of opportunities you have to improve your product.
Photo by Achim Pock on Unsplash
Post a Comment