I took Improving’s Professional Scrum Product Backlog Management class recently, and it landed like a natural sequel to the product owner courses I’ve taken before. The timing felt right. For many years, backlog management has been a regular part of my work: writing stories, prioritizing them, slicing them, refining them, and finding different ways to visualize them. Story mapping has long been one of my favorite ways to do that, and I’d just finished reading Value Proposition Design, so the themes were already close to the surface.
The class gave me a few new tools to try and reinforced a few things I already believed.
The user story hamburger
One tool I had not heard of before was the user story hamburger. It’s from the same author behind impact mapping, and when I first saw it, the structure looked a little odd. But once the instructor showed how it’s used, the color coding clicked. It makes visible which approaches you are committing to and which ones you are explicitly ruling out.
My first thought was that I could use the hamburger to generate outputs, then turn those around and lay them out in a story map. That combination felt promising, the hamburger for deciding what slices are in and out, story mapping for organizing the flow.
Where do product backlog items come from?
One exercise asked a simple question: where do product backlog items come from?
I read “where” as a place or context. I thought of a doctor’s office where a healthcare team works, or a meeting where leaders talk through goals and objectives. Those felt like real sources of PBIs. I wrote my stickies with that framing in mind.
The next activity asked us to place those stickies with the stakeholders who carry them. That is when the mismatch showed up. I had been thinking about where the work originates, not who brings it. The class used a stakeholder mapping quadrant, and my stickies didn’t map cleanly because I was thinking in scenes, not people.
That mismatch was useful. It pushed me from “who told us this” to “where did they get it.” If a stakeholder asks for something, did they get that request from their own customer? Were they watching customers operate in their actual environment? The same person in a meeting room may give me a very different PBI than the same person standing at a customer’s site, pointing at the real problem. That distinction matters. A stakeholder’s request is not necessarily what their customers need, and it is worth tracing the thread back to the source.
Owning the finish line
We also talked about assigning PBIs to a developer instead of breaking them into individual tasks. The common understanding is that a task may be owned by one person, but the PBI is owned by the team. I agree with that. It is a team sport.
But I would add one nuance: assigning a PBI to one person does not mean that person does all the work. It means they are accountable for getting it across the finish line. If they need help, they speak up. The team still does the work together, but one person carries the extra level of awareness for that one item so it does not slip through the cracks.
Measuring contribution without gamifying it
The class brought up the old warning about measuring activity by story points or source commits. I was reminded of a Scrum meeting years ago, and I use “Scrum” loosely there, where managers offered the team money based on how many story points we finished in a sprint. The whole team looked at each other and rejected it unanimously. We knew that would have broken the team dynamic. Someone who spends the sprint pairing, reviewing, and helping others push their PBIs across the finish line may not have a single commit or story point to their name, and that contribution is just as real.
What I’m noticing
I walked away with a few things I want to keep practicing:
- Try the user story hamburger and fold its outputs into a story map.
- Keep asking where PBIs come from, and keep tracing them back to the customer’s context.
- Treat PBI ownership as accountability for the finish line, not a solo work assignment.
- Stay suspicious of metrics that reward individual activity over team progress.
Good backlog management comes down to asking better questions:
- Where did this come from?
- Who is it really for?
- How do we get it done together?
Those questions sound simple, but they are easy to skip once the board fills up with work.
I’m also curious about what’s next. Improving has classes on metrics, facilitation, and agile leadership that all sound useful.
Leave a Reply