How to maintain a manageable backlog
5 Tips for maintaining a manageable backlog for your internal product.
Backlogs often get a bad rap because they become a dumping ground for an unorganized collection of things your product team could do.
You can attempt to bring order to chaos by avoiding a long list. User Story Mapping is one attempt to organize backlog items that is helpful when you build out things to support a customer journey.
Using boards to provide some visual representation of status can also be helpful. But only so much. If you have an inordinate number of items you have to shuffle through, things will get missed and you’ll start to dread backlog refinement.
Ultimately, in order to to have effective backlog refinement, you’ll need to keep your backlog manageable.
How backlogs become unmanageable
Backlogs tend to get unwieldy when they have too many items on them. There’s a variety of reasons that a backlog collects too many items.
A product team may create finely grained items way ahead of time in order to have 6 weeks of “shovel ready” work for the team.
Leadership may ask for estimates and the product team is only comfortable providing estimates by breaking work down and sizing it.
A product person uses the “That’s an interesting idea. I’ll put it on the backlog” coping mechanism to deal with stakeholder requests.
The product person adds every request and every piece of feedback on their backlog.
The product team started their efforts by brainstorming backlog items without any useful decision filters to determine if backlog items lined up with what they’re trying to accomplish.
It doesn’t have to be like that
With that in mind, here are five tips for building and maintaining a manageable backlog.
In subsequent issues of InsideProduct, I’ll go into more detail on the techniques I’ve found helpful for following these tips.
A few items, mostly big
I strive to have as few items as possible in my backlog. I also want most of those items to be fairly large in scope.
So when I say “big” I’m talking about a fairly broad scope and fairly high level information. This is the “reminder of a conversation” that you hear the folks talking about user stories blather on about.
Why do I keep most backlog items big and high level? Because backlog items are not like fine wine. They do not age well.
If you dive into detail to soon on a backlog item, you’re inherently going to add details in that are no longer true when you go to implement that particular item. You’re better off keeping items broad and only fleshing them out when you’re close to implementing them.
And ideally, you’d describe those items as problems to solve. Depending on your context, that may be easier said than done, which is a typic that deserves it’s own article (coming soon). For now, think about writing these items in a way that the product team understands what it’s about but leaves room to maneuver when it comes to implementation.
To really take this tip to heart in the last couple of years I’ve started using a product roadmap to track when the team is going to work on these large items.
The structure I use for the product roadmap is similar to a kanban board with four columns:
Now: Items you’re focusing on at the moment.
Next: Items you think you’ll tackle in the near future.
Later: Items that might be worth tackling at some point.
Never: Items you’re not going to bother with at all
Unlike a typical Kanban board the items move from right to left.
When you keep these bigger items in a separate view, it helps to reinforce the different levels of detail between these bigger planning focused items and the more implementation focused items that typically exist on your backlog.
And if you’re steeped in the agile phraseology of epics and user stories, the items you’d typically put on this roadmap may correlate to epics, assuming you use them as planning items.
Break items down only when you need to
Product roadmaps can help you keep a manageable backlog when you apply some simple guidelines and a little bit of discipline.
The guideline: don’t split an item down into small backlog items until it’s in the Now column of your roadmap.
The discipline: stick to that guideline. For the most part.
Use your product roadmap as a visual reminder of when something is ready to break down into smaller bits. The key is not doing it too soon so that you build up an inventory of backlog items that start to rot.
The for the most part comes into play that you may find it helpful to start digging into detail on an item when it’s at the top of the Next column and slated to be the next one to move over.
Prioritize on Impact
Another way to keep a manageable backlog is to be very judicious about what you put on your roadmap and subsequently your backlog.
The main criteria you use for putting items on the roadmap, and deciding which ones go to Now is how well they support you product strategy (if you have one) and help you accomplish your targeted outcome.
And if you use product strategy to make those decisions, make sure you’re using it as a filter, not a bucket.
I was very intentional to use the word impact here. You should start with what problem you’re trying to solve, and then do things that help you solve that problem.
It’s a subtle, but important difference from starting a new effort and getting a team together to brainstorm all the things you could do. That particular approach, a fairly common suggestion in agile training, is a road to an overflowing backlog.
Notice also I didn’t say “business value”. That particular term has become the “write off” of backlog refinement.
Telling people to prioritize by business value is not helpful. Because its left up to the hearer to define what business value is, kinda like the post office.
And yes, you could give the same argument about using the word impact. So I describe impact as something that helps you solve a problem.
Multiple Perspectives
The first three tips focused on how to decide what makes it on your backlog and how to handle them. This tip and the next one deal more with how you flesh those items out.
Regardless of what type of activity you’re doing in product development, it should be a collaborative effort that involves multiple perspectives. This is basically so you can make sure you can identify potential risks and avoid overlooking key insights.
This underlying principle shows up the most in prescriptions about who should be involved in some activity.
When folks talk about product discovery, they talk about the product trio. What they’re really talking about are the necessary perspectives to consider four risks:
Will users choose to use the product (value risk)
Can users figure out how to use the product (usability risk)
Can we build the solution with the time, skills, and technology we have (feasibility risk)
Does this solution work for various aspects of the business (viability risk)
When folks talk about backlog refinement, they often talk about the three amigos. What they’re really talking about is:
Have I described the problem I want solved?
Do I have enough info to solve this problem?
What happens when…
If you strip away the assumptions about your team structure and the nature of your product, these prescriptions are saying you need to make sure you’ve brought the proper people together to look at your problem and solution from a variety of perspectives so you can address the items above.
Hence, why people say “it takes a village” or “product development is a team sport.”
Get your team the information they need
I look at backlog items as a way to describe the solution so that your team can develop it. The secret is to finding the right amount of information. Your product team should have an appropriate level of flexibility to build the solution. They also shouldn’t have to ask a ton of questions or make a lot of assumptions.
I’d argue this is more important in internal products because you’re usually interacting with existing processes, business rules, data, and systems. There may not always be the same amount of legacy…stuff… you have to deal with in a tech company.
The most effective means I’ve found to figuring out that right amount? Ask your product team. Come to some agreement about what that is, and then adjust as you get some experience under your belt. You may use the idea of a definition of ready as a way to structure your conversation.
Some teams can work with the briefest of statements about what we need to do. Other teams require specifics in terms of business rules, data, and workflows.
As a general rule, I look to describe backlog items with a rough outline:
Overview: Provides the context for the backlog item and identifies the problem
Revisions Needed: where I describe the solution (this is where the level of detail can vary widely from team to team)
Business Rules (when needed): if a backlog item is implementing some business logic (for example, pricing calculation) I’ll pull those out separately
Acceptance Criteria: A set of criteria that explain things that need to be true in order for the backlog item to be considered complete.
Examples (when needed): If we need specific examples to confirm the acceptance criteria, I’ll note them here. Using real data and situations whenever possible.
When I’m creating this info, I try to be intentional about where I put information. If the information is relevant only to a specific change, I’ll note it in the backlog item. If the information will be relevant on an ongoing basis, I’ll put it in a separate file and link to it.
Examples of things I’ll put in separate files include process flows, data dictionaries, and api specs.
Enough about me, what about you
Those are some tips I’ve found helpful. Hopefully you may get some value out of them as well.
I also realize that all of you have had different experiences, so I’d love to hear your tips and experiences on working with backlogs.
What’s worked well? What hasn’t worked so well? What are some things you’ve heard about and would like to try?
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent