The Goldilocks Backlog
Weekly musings about life as a PM
Whenever we review our roadmap, product backlogs are always something that naturally get scrutinized. There are teams who are unsure of what they’ll be working on in 4–6 weeks time and conversely, there are others who feel that they have an extremely large backlog and that they don’t have enough resources to deliver the backlog. What do you do if you happen to find yourself in any of these scenarios?
Case #1
Scenario:
Recently in one of my teams, we realized that while we had a clear idea of the things that we wanted to work on, the relative priorities of each item wasn’t clear. So our backlog felt kinda like this:
Challenge:
It was great that we had a backlog but we didn’t have the clarity needed in terms of our priorities.
Case #2
Scenario:
In another one of my teams, we’ve been prepping for a few months for the launch of a new product and as we approach our deployment date our backlog started looking like this:
Challenge:
What to else do we need to do in order to launch the MVP, what should we work on next and do we have sufficient information for the team to work on it?
Case #3
Scenario:
In my third team, the team has been busy trying to scope out the details of some complex features should be implemented. The features are complex and require discussion across various product and engineering teams. As such scoping sometimes happen during the sprint itself. As the product is also complex from a business standpoint, they only have a general idea of what they might want to work on next and their backlog looks like this:
Challenge:
There was still a lack of clarity of the personas and use cases for feature C and understanding of how it rolls back up to the larger business objective.
What I Try To Do
Every team and scenario is different and what I’ve grown to realize is that there’s no sure-fire right way to ensure that you always maintain a healthy backlog especially given that there might sometimes be distractions or changes that causes you to have to change your plans. Some things I personally try to do:
- Awareness: Notice if I’m not spending enough time figuring what’s next and what’s in the future
- Plan: Allocate time for myself to work on whatever is lacking or missing in my present, next and future backlog items
Curious to know what I actually did? Read on.
Case #1
It was great that we had a backlog but we didn’t have the clarity needed in terms of our priorities. Our focus was then to work with the business to align on the relative priorities of each item based on the business impact and clarity that we had in terms of what needed to be done.
Before
After
Case #2
For this team, my main focus was to not only figure out what it takes to get the MVP deployed but also to start conversations with the business on what we wanted to focus on next based on a combination of use cases that haven’t accounted for in the MVP, known pain points or manual processes in place to enable the MVP to work.
Before
After
Case #3
In this case, because there’s still a lack of clarity of the personas and use cases for feature C and how it rolls back up to the larger business objective, we’ve (1) started conversations with our stakeholder to get that clarity and (2) figure out how we might want to break down the larger feature into a series of smaller releasable features.
Before
After
