This, in my experience, is the key to making the Product Owner role sustainable: represent the work so that you have the right detail at the right time, and then work right to left every day until you run out of time, and then stop. And then do it again tomorrow. You’ll get further left when you need to, but you don’t have to do it every day.
In this episode, Richard shares our favorite tool for helping Product Owners restore some sanity to their lives. The PO Board is a way to structure the Product Backlog so that the Product Owner knows exactly what to focus on, at what level of detail, and with which stakeholders on any given day.
Most Product Backlogs have too much detail, too far in the future, which causes a high level of churn and waste as many rather-detailed items never make it to the top of the backlog. It also, paradoxically causes POs to fail at both being sufficiently strategic and sufficiently tactical. They’re too busy to zoom out and look at the big picture for the medium to long-term. And they’re too busy to collaborate with their team in the details.
The PO Board models a Product Backlog as a Kanban system with work-in-progress (or WIP) limits for how much work gets represented at a particular level of detail. Closer to the top of the backlog gets more details, further out gets less. Richard made the first formal version of this about 12 or 13 years ago. Since then, we have been evolving the model to better fit our own needs and the needs of our clients. We’ve now taught this approach to thousands of Product Owners, and they regularly report that it has been a huge help in bringing some order to a job that is too chaotic and stressful far too often.
Some references to learn more about this approach:
Download the most recent PO Board Visual
Download “Managing Your Product Backlog” for details on using the PO Board
Read more about MMFs (Minimal Marketable Features)
Check out the full Guide to Story Splitting
Learn more in our online, self-guided courses: 2-Week Backlog Makeover and 80/20 Product Ownership.
The marked up versions of the PO Board from Richard’s walkthrough
Illustration of the overall structure
Illustration of some of the details
Episode Transcript
Richard Lawrence
So many Product Owners we encounter are overwhelmed and stressed; and at Humanizing Work, we’re convinced that work should help people thrive as humans. It should be sustainable. So, if someone is consistently overwhelmed and overloaded, something’s wrong. When we set out to help solve this challenge for our Product Owners some years ago, we discovered that a root cause for the overwhelm is too much detail, too far in the future.
This causes a high level of churn and waste, as many rather detailed items that you spent time refining never make it to the top of the backlog. It also, somewhat paradoxically, causes Product Owners to fail at being both sufficiently strategic and sufficiently tactical. They’re too busy to zoom out and look at the big picture for the medium to long term.
They feel guilty when they spend time thinking about big strategic things if they get to it at all. But at the same time, they’re also too busy to collaborate with their team on the details. They’re stuck in this middle range, dealing with too much detail there and missing out on both ends. To address this, we created a visual called the Product Owner Board or PO board.
The PO board models a Product Backlog as a Kanban system with work in progress or WIP limits for how much work gets represented at a particular level of detail. Close to the top of the backlog, items are more detailed, further out they are less so. I made the first formal version of this 12 or 13 years ago. Since then, my colleagues and I have been evolving the model to better fit our own needs and the needs of our clients by using it and helping others use it.
In this video, I’m going to introduce you to the latest version of the PO board as of mid- 2022. I’ll show how it shapes the day-to-day work of a Product Owner.
This is the Product Owner board. There’s a lot of detail here and a lot of tiny writing, because this is designed as an 11 by 17 poster that you can print out and look at the details. We include it in our workbooks for Certified Scrum Product Owner and Advanced Certified Scrum Product Owner. First, let’s look at the Product Backlog.
The Product Backlog is divided into three columns, more done, or closer to a Sprint, is on the right. Activities further in the future are on the left. So just like on any Kanban board, things are moving from left to right as they get done. On the far left here, left of the backlog, is “supporting context.” This is where, if you are actually visualizing this in one place, like on a wall, you might put a purpose, a vision, customer research, or a larger strategy.
If you’re doing this in a digital tool, this is more of a reminder that you need to visualize and share your supporting context alongside your backlog. Looking back at the whole thing again, to the right of the backlog, we have the Product Owner’s view of the Current Sprint. Work moves from the backlog into the current Sprint and then sliding over to the right of that, we have everything that is releasing: everything between completing backlog items in a Sprint to those getting out the door. This is a good example of something that we evolved empirically as we worked with our clients. Several of our clients were starting to try to model the things that happen after a Sprint because the Product Owner has work to do there, and eventually that became part of the full model.
Now zooming in on the backlog part of this, where the WIP limits matter, we’ve divided the backlog into three parts. At the top of the backlog, you’ll notice it says “Next Two Sprints,” because we found that for most Product Owners, for most products, at the user story level of detail, we like to have user stories at the top of the backlog, and we like them to be sized and split so that you could fit 6 to 10 of those in a Sprint.
We found about two Sprints worth of stories is as far as you can go before stories become too detailed and too volatile. If you go out to three or four Sprints worth of stories, Product Owners often find that the things towards the bottom of that list have some churn to them. They may never make it to the top, or by the time they make it to the top of the backlog, they’re no longer recognizable as the original thing. There’s some waste in there
We’re trying to balance making it long enough that you’re not always scrambling to be ready to plan a Sprint; but short enough that you don’t have too much detail, too far out, and therefore churn and waste in your backlog. And for most Product Owners, that’s about two Sprints in the future. So for the size we’re talking about, that’s 6 to 10 stories per Sprint. If you have one team, that means 12 to 20 stories max in that column.
The next column to the left labeled “Middle of Backlog” is about a quarter of MMFs (Minimum Marketable Features). We’ll link to an article on our website about minimum marketable features in the show notes here. MMFs at this point don’t have all the user stories that they’re going to get split into as they approach the top. You start to get those details just in time to fill the next column, and I’ll illustrate that in a moment.
Further to the left, we have more than a quarter out in the future. At about a quarter, MMFs are too detailed and too volatile for most backlogs, so we switch from a strictly prioritized stack of features to what we call a cloud of options with broad themes, maybe more vaguely defined features; and notice they’re not strictly prioritized; the more likely options are towards the top, the less likely ones towards the bottom. They’re not uniform in size. It’s a cloud that we’re drawing features out of. You might use our feature mining technique to do that if it’s a highly complex problem, or you might just use analysis and extending what you’ve already done to find features if you’re more in the complicated domain in Cynefin terms.
Now let’s look at what movement on the board looks like. Imagine that the Top of the Backlog column is full and you’re planning a Sprint. Now, roughly half of that column is going to get pulled into the current Sprint, which of course would be empty at that point.
The bottom half of that column is going to move up, and the whitespace that’s left behind is the signal that it’s time to take the top feature or two and break them down into more stories that can fill that whitespace until it’s full and you get two Sprint’s worth of stuff; and then you stop. It’s an example of a pull system where whitespace in a column to the right causes you to pull more detail from the left into that column until it’s full, and then stop.
That’s one of the ways we keep the Product Owner job sustainable. You’re only working on just enough at a certain level of detail until your column is full, then you stop.
Let’s clear this out and talk about the day-to-day of the Product Owner using this board. Day-to-day of the Product Owner is like it would be with any Kanban system, which is to start on the right and work your way left till you run out of time.
Let’s look at what each column is and the kinds of things that the Product Owner would do with things in that column, in a typical environment. Of course, your environment may be slightly different and, in those cases, you would do something different. Beginning on the far right, the column is titled “MMFs Recently Deployed.” This is where something is already in production.
I’m going to use software language here, although you may adapt this to other things. You’ve already released the feature that you are building. It’s out there in production. The Product Owner’s work at that point is things like monitoring how it’s going and whether people are using it. What feedback are you getting? So you would probably let things fall off this list after a certain amount of time, depending on your release cadence, and there are some things that you’re actively monitoring and getting feedback about, which will inform things that will go into your backlog. So that’s MMFs recently deployed. Moving to the left, “MMFs Ready to Deploy.” For these, you’re probably doing whatever you need to do in your environment to get something out the door. So there’s going to be some communication.
Sometimes there are things like user acceptance testing or other activities like that, although I encourage you as much as possible not to have active work in this column. Make it more about communication and moving the thing out the door. But whatever you need to do from the time that you’ve accumulated all aspects of a feature until it’s actually out the door. Finish that column, move to the left. The next column is “stories waiting for other stories that would complete the whole MMF.” This column is by and large a cue.
You’re not actively working on these stories very much. However, you are monitoring how close you are to finishing an MMF, because you might need to get ahead of some of the downstream things based on that happening.
Moving to the left, the next set is the “Current Sprint.” With items that are done in the current Sprint, the Product Owner’s role is typically preparation for Sprint Review.
Who do I need to invite to see this thing? Is there any work I need to do to be prepared to show this if it’s my responsibility on the team? Sometimes people mistakenly think that when something is in this column, the Product Owner’s role is accepting it as done. But that’s not the way this model works. Rather, something gets into that column because it met the definition of done, including the Product Owner accepting it.
Let’s back up into the “In Progress, Current Sprint” column. This is the place where a Product Owner collaborates with their team to actually get the thing done, including reviewing and accepting it, but also working together to get the thing to done, whatever that means. And the more complex it is, of course, the more close collaboration you’re going to have on the item versus just throwing specifications over the wall and reviewing things. In Scrum, the place where you would plan out that day’s collaboration, of course, is the Daily Scrum.
We’re asked sometimes if Product Owners should be in a Daily Scrum, and our answer is yes, absolutely. Because one of the things you’re doing is planning how you’re going to collaborate today on items in the current Sprint and also how you’re going to work together to get items to the left refined today. That’s “Current Sprint, In Progress.” Moving over to the next column “Current Sprint, Not Started,” this is another column that by and large is a cue because the team knew enough about these items that they’re sufficiently elaborated to be pulled into a Sprint, but no work has started on them yet because they haven’t been pulled into “In Progress.” So not a lot has changed here. You don’t have to do much. The one exception would be sometimes we see lower priority items that have some kind of impediment on them that the Product Owner can resolve.
For example, a team might pull an item into the Sprint that’s lower priority and say something like, “We need to go get some questions answered on this one and we can’t start it until we do. But it’s probably going to be six or seven days till we get to it in our two-week Sprint. So we’re going to pull that in but put an impediment on it, and as long as you can get that resolved by the time we get there, that one will fit in the Sprint.” So that’s about the only thing I see Product Owners actively doing in here. I’m surprised when I ask groups what the Product Owner does in this column, how often I hear “prioritize items,” because it’s puzzling to me that priority would change between Sprint Planning and partway through a Sprint. If that’s happening a lot for you, that is a smell. I would look into why that’s happening and what you might do about it.
One thing to notice about this view is that there are two lanes. There’s a top lane with features moving across through a Sprint, and the bottom section with the yellow cards, the user stories, moving across.
You can see here “feature seven” and this “F7” on several stories. What this indicates is that this feature got broken down into these stories. The status of this feature can be inferred from the status of the story. We didn’t have that in early versions but found that it was useful to be able to see the state of things at two different levels of detail because that’s relevant for different audiences.
Now, moving out to the backlog, what does the Product Owner do with items at the top of the backlog? Well, a lot of what we think of as typical backlog refinement: splitting, sizing, elaborating details, maybe getting wireframes on things, thinking about scenarios or tests, acceptance criteria, whatever it is you do in your environment to get a story ready for a Sprint. I will say, what “ready” means can change for different kinds of items with respect to their complexity.
Many of our clients tag items in this column with “primarily complex” or “primarily complicated” in Cynefin terms to indicate, on the Complicated side, that this is a thing where we should specify a lot of detail because we can in advance– it’s an analyzable, ordered problem; or on the Complex side, this is something where we’re not going to have all the details to start because we’re going to learn as we work on it.
And that distinction helps them tease out when an item is sufficiently refined in this column to be ready to be pulled into the next one, which happens, of course, in Sprint Planning. On top of the backlog, once you finish refining that again, only two Sprints out, you’re ready to move to the next column, “Middle of the Backlog.” This column has some fleshing out of details and features, but not too much.
Sometimes there’s new user experience flows that’s probably happening here, (you might be doing some customer research to understand these things more) these move fairly slowly because they’re bigger and more vague, and that’s appropriate as they get to the top. And you’re going to need to break them down, you need more information. So we deliberately keep them larger and more vague in here.
It is possible to size features relative to features and stories relative to stories, and measure the relationship between those two scales, which allows you to do some projection. When are we likely to get to particular features in the backlog? Now that really only works as long as your team is working through them in priority order. A team that multitasks across multiple features will find it really difficult to predict when any particular feature will be done.
That’s the Middle of the Backlog. Finally, Bottom of the Backlog, things more than a quarter out; over here, we’re doing more strategic work like thinking about big strategic steps and vision and what options we should be pursuing. These are much bigger and more vague even than features, because it makes sense to do strategic thinking at a high level and preserve your options.
Now, you’re not going to get to all of these every day most of the time. You’ll start on the right, you’ll work your way left until you run out of time. Most days you won’t get all the way to the left. And that’s okay because the things on the left move more slowly. When you do get to the things on the left, you can work on those bigger strategic things with confidence that the things on the right are already taken care of. They’re in good shape for that day. And this removes the tension for Product Owners between tactical and strategic work. You’re kind of always doing both, but you’re only doing the slow moving strategic work when you’re comfortable that the tactical is taken care of and you’re keeping the tactical section small enough that it doesn’t bleed too far into the future and eat up all your time you would spend on strategic work.
So it’s a balance between the two levels of focus.
You may find that you get too much churn or you haven’t planned far enough and you can adjust the WIP limits, make each column bigger or smaller. But these sizes on the poster are the ones that have been the most common across our clients and our own work. And so I think they’re a good starting point, and then you can experiment from there.
Now far left, “Supporting Context,” these are things that you may revisit quarterly, you may take on when you’re bringing a new initiative into your team or there’s a larger thing coming down the line and it’s time to rethink your vision or your strategy. Those get revisited, but it’s usually based on calendar or external events that caused you to do that.
And then finally there’s this “Someday Maybe” box sitting at the bottom of the supporting context. We found it useful sometimes to visualize the things that we’re not doing right now. They’re intentionally not on the backlog, and this may include things that are waiting on something else to happen in the world. Like maybe you have cryptocurrency payments as a thing you could do one day, but it’s not widespread enough that it’s worth putting on your backlog; so it sits there to represent “we know about this. Maybe we’ll look at it every quarter and see if it’s time yet, but it still sits there.” You might also put things out there that are likely to never come into your backlog, just as a way to say “before you ask for this, know that we know about it;” and maybe there’s some information on there about why we’re not doing it.
This, in my experience, is the key to making the Product Owner role sustainable: represent the work so that you have the right detail at the right time and then work right to left every day until you run out of time and stop and then do it again tomorrow. You’ll get further left when you need to, but you don’t have to do it every day.
So that’s the PO Board. I’m curious if you’ve tried this or if you tried something like it, and what you experienced as you did it. If you put this into practice in your environment, let us know how it’s working for you and what questions you have and we’d love to follow up on that.
As always, thanks for watching, and be sure to like and subscribe so that other people can find this and so that you can get notified when we produce more content like this.
Last updated