These mistakes make it overwhelming for Product Owners, frustrating for teams, and ultimately ineffective for everyone involved. But once you fix them, every day involves a little more refinement, just enough, just in time. No more huge backlogs, no more churn and rework, no stress leading up to sprint planning, no three hour refinement meetings no one really enjoys. Just calm daily progress.
Backlog refinement is critical for any agile team—if your backlog isn’t in good shape, everything downstream falls apart. But there’s a common set of mistakes almost everyone makes when it comes to backlog refinement, mistakes that make it overwhelming for Product Owners, frustrating for teams, and ultimately ineffective for everyone involved.
In this rebroadcast of the July 2023 Humanizing Work Community Meetup session, Richard looks at those top 5 backlog refinement mistakes and how to fix each one.
We host these free community meetups on the third Thursday of every month. Sign up for future community sessions at https://www.meetup.com/humanizingwork/
Episode Transcription
Peter Green
Welcome to the Humanizing Work Show! This episode is a recording of our July 2023 community meetup session, where Richard shares the Top 5 Backlog Refinement Mistakes Almost Everyone Makes. The title doesn’t mention it, but, just to be clear, he also shares what to do to prevent or correct those mistakes.
We host these free live community sessions on the third Thursday of every month. So if you want to attend future sessions, where you can participate in the chat and Q&A, sign up at meetup.com/humanizingwork/
Now on to Richard:
Richard Lawrence
So we’re talking Backlog refinement tonight.
Backlog refinement, as I know a lot of you know, is critical for any Agile team. If your Backlog’s not in good shape, all the downstream stuff falls apart. And it turns out there’s a common set of mistakes that I see over and over again on teams. Mistakes that make it overwhelming for Product Owners, frustrating for teams, ultimately ineffective for everyone involved.
So we’re going to look at those top five mistakes and how to fix each of them tonight. Before we jump into it, I’m going to ask a question in the chat. I’m curious about your experience with backlog refinement. What is the hardest thing about backlog refinement for you and or your team?
Right. I think a lot of these are going to intersect nicely with the things we are already talking about and where they don’t. Obviously, we will make sure they do. The first thing I want to make sure we’re aligned on before we get into the mistakes, is why good backlog refinement matters.
There’s kind of a chain of cause and effect or a good Sprint Backlog increases the odds of a good Sprint, a good Sprint planning meeting increases the odds of a good Sprint Backlog, a good product Backlog increases the odds of a good planning meeting and good product Backlogs happen from good Backlog refinement.
So let’s work our way backwards from what I mean when I say “good” in each of those sentences. And I think that will make it clear why some of the mistakes are actually mistakes. So starting at the top, I would define a good Sprint as one where there’s a sense of shared purpose, where a team collaborates every day, where the Sprint finishes with a valuable product increment, ideally where there’s new visible value coming out of the team every day, not just at the end of the Sprint.
So you can see already, probably, how that very much depends on the quality of the Backlog. So backing up a little bit, a good Sprint Backlog needs to make that outcome more likely. That means there should be a clear sense of shared purpose in the Backlog. This is our work pointing towards a meaningful goal that we share. Every Backlog item should represent an increment of value and the Backlog collectively should represent a reasonable, sustainable commitment.
There should be enough small items to respond to change by dropping or adding, not just one big bet. Backing up again, a good planning meeting: That would be one that leads to producing that kind of Sprint Backlog. So it’s going to be collaborative. We’re planning our work together. We’re not just collecting random sets of tasks that’ll keep everybody busy.
It should probably be low pressure and empirical– not we must complete all this stuff, whether it fits or not, or worse yet, what I see sometimes, here are the things that were assigned to our team for the Sprint. We don’t want to see that. The meeting should work toward a reasonable level of certainty, but not too much certainty.
Like we’re not trying to know everything, but we are trying to have some level of confidence because the world is complex.
And I think, backing up in the chat here, yeah, like Pam’s thing about getting the team to ask questions to ensure they understand; probably a lot of times they think they understand until they discover later that they don’t because the world is complex. So that suggests we need some kind of planning that allows for that. Like, let’s do everything we can to make sure we have alignment, but let’s also be able to respond when we don’t.
So that’s good Sprint planning. Backing up again, a good Product Backlog is one that’s going to be organized into clear slices of value, each of them small enough to fit nicely into a Sprint, and those slices of value should be traceable to larger items like features and ultimately a big vision or purpose. And for those of you who mentioned a challenge about scale there in the Backlog, like focusing either too big or too small, I think this gets solved in the Backlog.
And we’re going to look at how a little bit later, because we have to have that connection between the big things and the small things. Otherwise, we’re going to end up focusing on one or the other based on where we are most interested or where stakeholders are pushing us. The items in your Backlog, if you’re having a good Backlog, should have enough detail to reasonably assess whether they’ll fit into a Sprint, but not so much detail that it’s likely to be wrong as we learn more.
The way I often put it is enough to start– not enough to finish– without collaborating more.
Finally, backing up to the beginning of this chain of cause and effect, good refinement is whatever set of practices reliably leads to all those other outcomes I’ve talked about.
Ultimately, and unfortunately many teams make the same set of Backlog refinement mistakes that really sabotage their effectiveness. So I’m going to talk about five of those today.
All right, let’s get into the mistakes. So, mistake number one is detail too early or too late?
Good Backlogs have this kind of Goldilocks dynamic to them. The right amount of detail just in time. If it’s too early, we get churn and we get rework in the Backlog. If it’s too late, we’ll be scrambling to get ready for Sprint planning and we’ll miss important details.
Now, most Product Owners know this, but actually structuring your Backlog, structuring your day so that you end up with the just right Goldilocks goal here is really hard.
So most teams end up oscillating between those two extremes. They’ll over plan for a while, then they’ll find themselves under planning and scrambling and then we can’t let that happen to us again. So they go back to over planning and struggle to find a stable, healthy equilibrium. Here’s how you know when you’re getting it right: Good Backlog refinement feels like progressive elaboration. Items steadily move up the Backlog and as they move up, they get split into smaller items and they accumulate details. If your Backlog feels like churn, like you have to create lots of stuff out of thin air, that’s not that kind of calm, steady elaboration. When Backlog items get stuck, when they don’t move up, that’s a signal that there was too much detail too early– that an item wasn’t ready to be specified at that level of detail.
Likewise, when an item has details that get changed in a future refinement session and then changed again in the next session, so you’re touching the same item multiple times at the same level of granularity. That’s another signal that there is too much detail, too early.
I’ve been surveying Product Owner classes for years with two questions:
First question, how long is your Backlog? And if you’re a coach, pick a typical team that you work with, perhaps. All right. So we got a range there from a few Sprints out to years. And here’s the second question. The one that really makes it interesting when you combine the two, What percentage of those items on your Backlog will never hit the top? Something will always jump over them. Or by the time they get to the top, they’re unrecognizable?
And so as I’ve surveyed hundreds of people with these questions over the years, and if you picture kind of a bell curve around this, the center of the bell curve on the first question is 2 to 4 years of Backlog.
And on the second question, it’s 50% to 80% of items will never hit the top. In other words, most Product Owners are managing hundreds of Backlog items that will never turn into product. It’s just waste and noise for them.
So most people are on that detail- too- early end of this pendulum, which kind of makes sense because it’s way easier to add an item to the Backlog than it is to actually build the item.
So there’s relatively little friction when it comes to, “Well, I’ll just throw it on the Backlog” and then once something is on the Backlog, you may have noticed the question changes from, “Is this a thing we could build?” to “When am I going to get that thing?” Once it’s on there, it’s kind of an implicit commitment, which means you’re probably going to end up talking about it and adding detail to it.
Yeah. Michael, let me give you my definition of Backlog: I’m using loosely right now the scrum definition, which is essentially all the things that we’re pulling from to build and the list of things our team is going to build.
Now I’m going to put a little more of a fine point on that as you’re probably anticipating, because in the Scrum guide, it says every idea everybody has goes on the Backlog. It really is the place where people’s dreams go to die because there’s always more than there is capacity. Although I say that all the time, next week’s Humanizing Work Show, you’re going to hear about the other case, where people actually do have more capacity than they have Backlog items. But for most of the people we work with, the Backlog is way longer than they actually have capacity for. And so the Backlog is just all those requests, those things we intend to build. Yeah, Lee’s comment is an interesting one: “Does the frustration increase as the churn goes up?”
I think it does, because that represents work the Product Owner did that will never turn into anything and we want our work to matter. And that’s where we get our sense of value and contribution. And so for the Product Owner, if a lot of your work is going into Backlog items that just sit there on the Backlog, it’s demotivating, it reduces your sense of purpose and mastery and probably autonomy, because if they’re sitting there and you’re touching them over and over again, there’s probably a sense of “I wish I could pull this off the Backlog.”
So what’s the fix for this? If you’ve got too much detail too early or if you’re at the other end of the spectrum where you’re finding yourself breaking down items and adding key details during a Sprint Planning meeting, which would be the opposite, there’s a signal there’s too little Backlog refinement happening. You’re doing Backlog refinement during planning, which is the last and worst moment to do it.
So if you’re on either end of that, what’s the fix?
The fix is to shape your Backlog so that it tells you when it’s time to add detail at a particular level of granularity. And that’s the PO Board model that we teach. So you may have seen this before. We’ve talked about it a lot. I talked about it in depth on a Humanizing Work Show episode, which we’ll drop in the chat.
So let me give you the quick overview if you haven’t seen this before. This, I think, is the secret to getting your Backlog under control so that it gives you the right level of detail at the right time.
So I was working with a product owner some years ago and she was overwhelmed. Her team was actually pretty calm and sustainable. And one of the ways you knew that, was that 5:00 o’clock came around and the whole team left the office, which was at the top of a hill above the center of town in Trento, Italy, and the team would leave the office, go down the hill into the center of town for happy hour at 5:00 every day, like clockwork. And the Product Owner would usually be going into a meeting at that point. And when I talked to her about what was going on, why she always had these 5:00 meetings and how late they were going, I discovered that she was spending 60 to 80 hours a week on her work and still felt like she couldn’t keep up with her two teams.
It was always stakeholders wanting to add more things to the Backlog, having meetings about them, and the meetings a lot of times were literally, “I’ve written a requirements document for this project you’re going to start in six months and I want to read it to you on the projector. So let’s schedule a meeting at 5:00.” It was about as bad as that could be.
So in order to get her backlog under control, we started looking at how much you can know, at a particular level of detail. So on the PR board, the Backlog is this section and it’s divided into three parts, the top of the Backlog, the middle of the Backlog, and you won’t be surprised– the bottom of the Backlog. The top of the Backlog I like to model is User Story.
So I asked Angela, this Product Owner, how far out can you go before you start having churn with your User Stories? The answer, it turned out, was about two Sprints. I asked around, at other clients and past clients, and the answer pretty much hovered around two Sprints. You get beyond two Sprints at the level of detail of User Stories and you start getting that churn. Things hop over them or the details change over the next month or so.
Now you’re running maybe shorter Sprints or longer Sprints, this shifts one direction or another perhaps, but, as a rule of thumb, as a starting point about two Sprints at the story level of details is about all you can have.
So we made this like a Kanban system and we said, “Okay, at the top of your Backlog, the path where you get down to the story level of detail is only two Sprints long and in Kanban terms this is the WIP limit, the work in progress limit for Backlog Refinement to Sprints worth of stuff once it’s full, no more stories. That’s enough at that level of detail because anything beyond that is going to be waste.
Then we slide over and the next level of detail that I like to use is Minimum Marketable Features, which we have an article about on our website, and when I asked that Product Owner and others about how far out you can go with that level of detail, the answer was about a quarter. You go beyond a quarter and it’s hard to say, “Here’s the next feature we’re going to do,” so when that column’s full, no more features. And then beyond that, you can go as far as you want, but we need to be pretty vague out there.
And if you look at that, you’ll notice this phrase “cloud of options” at the top, because I like to model the bottom of the Backlog without even strictly prioritizing things. They’re just “here’s a bunch of options, more likely ones of the top less likely ones at the bottom.” And we draw features and then stories out of those so we can say, “Yeah, sometime in the next couple of years we will probably do this thing. But if it’s really important, we need to have a conversation about it. It probably should move up and get broken down into features and end up over here.” And if you’re not ready to do that level of commitment, we’re not ready to talk about it much at this point. Yeah, sorry. Most tools fail at most of this.
So this is more of a conceptual model. Although if your team is in person, you may be able to do this really nicely on a wall. So if we want to have the right level of detail at the right time, we need to structure a Backlog so that it has the right amount of things at each level of detail.
The focus right now is the Backlog portion of this, but I’ll quickly wave at the other parts of it.
And then you can watch the Humanizing Work Show video for a more detailed overview of it.
Since this is a Kanban system, work moves from left to right to get to Done so in the left, things are vague ideas. They’re getting more and more information turning into user stories, eventually making it into a Sprint. So at the beginning of a Sprint, this would all be empty.
About half of this column would end up moving into “not started” in the current Sprint. The other half would move up. The white space left behind is a cue to you as the Product Owner to make more stories and then when the white space runs out, no more stories.
And of course, those stories will come from the top of this column, splitting up the top of that column, which will make white space, which is a trigger to make more features, which you’ll pull from the next column, which will eventually pull that up, which is the trigger to make more strategy and that sort of thing. So as something happens to the right, it pulls things from the left.
And when do I need to make more detail? When there’s white space to fill in the detail or when something is approaching the top of a column like we’re getting towards from planning the things at the top of this, top of the Backlog, will want probably more detail. So this kind of structure to a backlog is telling you what information it needs, when and when you can stop. So you have the right level at all times.
And then we model what’s going on in the current Sprint if it’s useful. And then to the right is what’s going on downstream of the Sprint. Once a team has stopped building a thing, what still needs to be done to get it out the door?
And then to the left we have just whatever supporting context would go with this. And of course, if you’re using a tool like Miro, the supporting context can live right there next to the board, just like it would on a physical board. If you’re trying to do some kind of Kanban representation in a Backlog tool, this is more of a reminder to bring these things to your conversations.
When you’re doing Backlog refinement, make sure you’re setting things in the context of a larger vision, perhaps, or strategy or customer research or whatever it is that you do.
I think a lot of times Product Owners get frustrated that their teams don’t really seem to understand the big picture or don’t understand why they’re doing things. They get buried in the details and it feels like the team’s just not paying attention. But what’s actually going on a lot of times is the curse of knowledge–cognitive bias– which is the big picture stuff, is so obvious to us because we’ve been thinking about it so much that we assume it’s obvious to everybody else and don’t talk about it enough.
The right amount of communicating this stuff is going to feel like over communicating because by the time we’ve got it to a point where it’s ready to share, it’s painfully obvious to us and we’ve thought about it so much and our brains, have a nice shortcut where we forget that we learned a thing and it just becomes obvious to us, which is good at keeping us alive.
But it’s not so good at building alignment with the team. So we need to remind ourselves that we’ve got to communicate this a lot. So when we’re working on a story or setting it in the context of a feature, we’re explaining how the feature points to some larger strategic step which will achieve some vision. And connecting those dots is really important.
I actually just experienced this today for a product that I’m the Product Owner for and I’m working with one developer on this software startup. The developer is my son and we talk about stuff all the time. So I would think things are obvious to him and he’s working on a change to how billing works for this product, and I thought it was totally obvious why we were doing it.
And then a question came up that revealed we’re thinking about this differently. So I had to go back and tell the whole story. Why are we making this change to billing? What impact will it have? How does it ultimately come down to this particular workflow and feature that he is building? So you can do a lot of the conversations, have the Backlog refinement sessions, think you’re pretty well aligned and then discover, “Oh, I didn’t connect the dots enough,” and it wasn’t necessarily either of us doing anything wrong. We thought we had alignment at the time, but it’s just a reminder to keep telling the big story that connects the dots to the small things.
All right, so that was mistake number one. Detail too early or too late.
And if you’re getting the signals that it’s too detailed, too early, like lots of churn, that’s a sign your columns are probably too long here. If you’re getting the signal that you’re getting detail too late, which is scrambling to plan, then your columns are probably too short and you need to fill in some of the detail up top.
Let’s go to mistake number two.
This one is a little bit unorthodox in the Scrum trainer community, but I stand by it. Mistake number two is refinement as a meeting. I’ve said before and you can quote me on it, you need a Backlog refinement meeting about as much as you need a programming meeting.
You probably don’t have a programming meeting. It’s just the work that programmers do. And to do it they need to collaborate with other people like Product Owners. In the same way, Backlog refinement is just the work. It’s the Product Owners job. It’s a job that’s going to require collaboration with other people, both on and beyond the team.
But that collaboration doesn’t need to be concentrated into one big meeting.,
Much of Backlog refinement is better done with pairs and small groups like Product Owner and developer or Product Owner a developer, a tester Product Owner and a subject matter expert or something. And it’s often best done in multiple passes. You work on a little bit together.
Then the Product Owner goes and works a bit on their own or gets answers from other sources, comes back together, shares the new information. Really there’s only one Backlog refinement activity that requires the whole team, and that’s estimating if your team estimates the size of Backlog items everyone should participate in and own that.
You don’t want the most experienced team member telling everybody how long it’s going to take. Everybody should own the estimates, but pretty much everything else can be done in smaller conversations. And then when you get to things like estimating, it’s going to draw out that information from the previous conversations, because you’ll need it to put an estimate on things.
I like to coordinate this at a Daily Scrum or daily stand up kind of meeting. So people ask me sometimes, should a Product Owner be in the daily standup? Scrum Guide says they’re optional. And my answer is they’re very much not optional for two reasons. One, if you’re doing complex work, the rest of the team needs your help, and the place where you plan that is your daily stand up.
And two, you need help from the rest of the team on Backlog refinement and the place where you plan that so that it’s not an interruption to the rest of the day is daily standup.
Let me ask you this: Would it be useful to talk more about how you would manage Backlog refinement if it wasn’t a regularly scheduled meeting with the whole team? My favorite way to do it is to let this PO board, that Backlog structure I mentioned on the previous one, tell you as a Product Owner what information you need and then you go to your team and in your daily stand up and it’ll sound like I’ve got this new story coming up, the Backlog gets a little bit bigger than we normally like. So can a couple of people help me split it today for 20 minutes? And you build that into your day and then you come back the next day. “Yesterday, we split this thing. We think it’s small enough now; can we have the whole team do a round of estimating at some point and jump right in on that?” And so it’s that– raise a conversation that needs to happen.
Invite people to work with you on it, share the results of it to do the next incremental thing. And I think of it as what decision do we need to make next? Throughout the Backlog, throughout the life of the team, there’s this whole series of decisions you need to make that will require you to have conversations and then you have those conversations with the people you need to have them with and do it little by little every day.
And because teams are often distributed now, you may still want to have some kind of placeholder on the calendar as kind of catch up for things we need to talk about. But be super careful with that because it often turns into 2 hours of mostly conversations that didn’t require everybody. And that sense of waste weighs heavily on a team’s morale.
And it’s a pretty expensive meeting. If a typical Scrum team in the U.S. costs a million and a half to $2 million a year and loaded cost, it’s like $7,000 to $10000 a day for the team. So if you get that whole team together for a couple hours, you’re burning a couple thousand dollars. And it may not be the most productive couple thousand dollars, not to mention the morale effects of doing it.
So I would shy away from those big meetings and just do lots of incremental things. And by the way, a funny thing that I’ve noticed is in daily stand ups, when people describe what they were doing yesterday, you’ll hear things like, “Yesterday, Angie and I worked together on the change to the home page on the website,” which is in fact true.
And then “I had a meeting with a client about this thing.” Notice objectively, both of those were meetings, but because I felt like Angie and I accomplished something in that meeting, I just described it as doing a thing with somebody. And pay attention to this. When you hear your team talking about stuff, they will talk about two different things that are both objectively meetings. They landed on a calendar. They involved a Zoom call. They were in a room together. They use the word “meeting” to refer to the ones that felt vaguely wasteful or ceremonial, and they’ll use different words to describe the ones that didn’t. We want Backlog refinement to be a thing that nobody ever describes as a meeting.
It’s just collaboration that we have together.
All right, let’s keep going. That was mistake number two. Let’s get mistake number three, which is horizontal slices. And in case this is an unfamiliar term, let me explain real quick. Software architecture diagrams typically show the major components of a system as layers. The top layer is a user interface. The bottom layer is a database or some other kind of persistence.
The middle of this is where services and logic live. So a complete feature of a system like this lays on top of the architecture as a vertical slice– show you a picture.
So vertical slices, are these lines going all the way through the architecture because you have to touch multiple layers in order to get a complete increment of value.
The trouble is that vertical slices are often large; too large to fit nicely into Sprints, certainly too large to get several into a Sprint so we can see meaningful progress every day.
But slicing big vertical slices into small vertical slices is hard. Everyone struggles with it, which I know, because about 15 years ago I published a poster with several patterns for splitting big User Stories and features into small User Stories, and unexpectedly is the most popular thing I’ve ever created. Like they’ll probably carve it into my tombstone when I die, which I did not see coming. At this point, there’s like 2 million downloads and 11 languages that’s been translated into, which tells me people everywhere are struggling with this.
And what often happens when people struggle to take this big vertical slice into a small vertical slice is they end up doing this instead, which are horizontal slices. Let’s build a little bit of the UI, let’s build a little bit of the middle layer, let’s build a little bit of the back end. Worse yet, some organizations even structure teams like this so nobody can build a complete slice of value.
But assuming we have a team that can actually build a complete slice of value, we don’t want to organize the work like this. So if your Backlog refinement is producing horizontal slices in your Backlog as you try to make things smaller, there’s a better way. Check out that Humanizing Work guide to splitting User Stories, which includes the poster, which I won’t go into much now, but how to split a User Story.
And one thing I want to call your attention to on that guide to splitting a User Story is there’s a section down in the middle on how to get good at story splitting, that talks through how to practice this with your team. One of the things that surprised me as I’ve been teaching this for several years is how learnable this skill is. There are a lot of things that individuals and teams do that take hundreds or thousands of hours to get good at. Story splitting takes something like 3 hours to go from zero to fluent, but it requires 3 hours of deliberate practice.
And so check out the bit in that article about how to do that. This is a thing to, I think, actively watch as a team. And it’s, you know what I often say about things in the complex domain, is that they are easier in practice than in theory.
So I’m talking theoretically and hypothetically right now trying to come up with a general case which is really hard for something like this. For a particular team, you can kind of watch where we’re swinging too far one way or the other. So let me talk through how you think about that in practice: so at one extreme, we do everything in meetings so that nobody misses anything. And I know a few teams that go all the way with this, like they code everything together in meetings.
Literally all their work is as a team. Mob programming is one name for this and it creates a great deal of alignment and you end up with more creativity in some things, but it’s also super expensive for things that don’t really benefit the most from it. So it’s kind of a bet that we’ll benefit enough from a high level of alignment and creativity from having everybody together that it offsets the extra overhead of having everybody together.
That’s one extreme. At the other extreme, you have the teams that tell us “We can’t collaborate because it’s way more expensive for us,” or “It’s way more efficient for us to work separately.” And so each person grabs their own thing and works on it separately. That’s kind of the other extreme. We do as little together as we can.
I think Backlog refinement sits right in the middle.
There are some things where you would say this is a new area that we’re working on. We need to get everybody aligned around it really well. This one’s probably worth the whole team.
There are other things where it’s, you know, we’ve seen a lot of things like this before. We need a little bit of a technical perspective in the conversation, but nobody’s going to be surprised really, how we split it.
This is another one of those familiar things that we’ve done a lot of– like the third workflow of this kind is coming to our team. We know how we split it the previous two times. We need to have a conversation with maybe one technical perspective, one product perspective to make sure nothing is different here. And we go back to the team– everybody’s going to understand it.
So I think what I’m calling for here is not getting rid of meetings altogether or getting rid of whole team thinking, but rather using it in places where you really benefit from it, where the complexity is high, where things are really new, where you actually need alignment, like estimating. In places where it’s not that complex, it’s not that new, I’m giving you permission and encouragement to do it outside of a whole team meeting, in smaller conversation; and not even necessarily for the sake of having meetings, just don’t have meetings for everything out of inertia because this is the way it’s always done. I would suggest a bias in the other direction, which is “Can we do this with a smaller conversation and bring everybody else up to speed?” And where the answer is, “No. This one is the kind of thing that requires everybody together” versus the opposite.
And I would do the same thing with programming, for example, when I’m at the beginning of some new area of a product like the first slice through a workflow or something, I love having the whole team build it together because you get good alignment around how are we going to do this thing? And sets it up so that people can then work separately and accomplish more.
So yeah, common sense does apply and is not as common as we would like it to be. So let’s think carefully about what really requires a whole team meeting. What benefits from smaller conversations and Story Splitting is another one of those things. I would suggest if you’re going through the practice for learning to get good at Story Splitting that you do that as a whole team because what you’re doing in those learning sessions is trying to build a common language for what does it look like when we see this kind of pattern? What does it look like when we have a workflow in our product? What does it look like when we have multiple business rules on something and how do we split through that? What does it look like when we have data variations? So all those patterns on the story splitting poster, you’re really looking back to find examples of them and see what that looks like so that it becomes a pattern recognition problem, instead of this big, complex swirly thing.
Yeah, I agree with Lee’s comment there. New team members, include them in more things so that they see how the team talks about it. So even if we were looking at something that didn’t require the whole team and a more senior member was going to step up and help me split a thing and add a new member on my team, I would say let’s pull them in as well so that they see how we talk about it and start getting familiar with it. So when I have new people, I want to include them in more things.
Let’s go to mistake number four, which is allowing technical dependencies to take over the Backlog. Backlog refinement can easily become an exercise in dependency management rather than an exercise in maximizing impact and a sign that this is happening is that you see yourself prioritizing so-called quick wins or foundations or enablers.
There’s various words for this, but it’s the things where we should do this because it’s quick or because something else will get built on top of it, but not really for its own sake. If your team is like most agile teams, your team exists to create something new in the world to meet a human need. And creating new things for humans is an inherently complex activity.
So the closer you get to the core purpose of your product, the more complex and the more unpredictable the work is likely to be.
And on a lot of teams, prioritizing quick wins or technical dependencies is often an attempt to avoid that uncomfortable complexity. Like, this is a thing we don’t understand much. It’s– we’ll know more later. Let’s come back to it later. Let’s build some things that will lead up to it. Let’s do something that we can get a win with faster. All those things are avoiding the very reason why your team exists, which reduces the value you produce and increases the risk that you’re carrying around. So instead, you want to move towards that complexity. When you find yourself focusing on dependencies instead of impact, ask “What are these quick wins, or are these enablers causing us to delay? What are we not doing because we’re doing these?”
And the flip side of that, “What’s slice of this new important thing could we go to as quickly as possible? Or how can we learn what our customers really want by getting something real in front of them as quickly as possible?”
Let me tell you a story about this:
Some years ago, I was working on a team that was doing a really complex system to help wastewater engineers optimize wastewater plants. This was a thing I didn’t even know existed. But it turns out there’s this whole thing around cities growing faster than their infrastructure can grow. And so wastewater engineers will help a city or county or whatever try to get more capacity out of existing infrastructure.
In this case, you’ve got a new housing development producing a lot more sewage and it needs to go somewhere. And so that requires some work. And it turns out that these engineers.
were really good at finding new capacity in existing wastewater plants, but it was really manual time consuming work. They had to look at a ton of data about what’s going on in the inputs and the outputs and things like that, and crunch the numbers and figure out what to do.
So my team was brought in to build a system to make that easier work, to collect the data coming out of the plant, get it in a data warehouse and make it easy to make some recommendations for how they could make their plants run more efficiently.
Now the company I was working for at the time didn’t do a lot of agile work, but they did do a lot of data warehouse and BI decision support kind of products at the time. Those had a pretty typical flow to them, which was spend six months to a year collecting the data and building the perfect data warehouse, spend several months building cubes and reports and things on top of it, and then eventually get it in front of a customer and discover that you missed something important and then spend several months redoing a lot of the work until you finally get it right.
Well, we wanted to do something different. We wanted to get to real value as quickly as possible and not wait a year and a half for that to happen. So we pulled in some of the wastewater engineers who were just getting started on a new optimization project, and we asked them, “What is a question you would really like to be able to answer next week, but you can’t right now?” And we asked a few rounds of that, like, “What are the questions you’re always looking to answer at the beginning of one of these things?”
And then we decided to build the world’s simplest data warehouse and reporting system to answer that question. So the data warehouse was a flat file of data that was pulled out of the plant, copied on to a disk somewhere, the reporting system was a web page that did a table and a graph on top of that, shipped at week two. They saved $1,000,000 by using that, and we just repeated that the entire time.
Now, of course we did actually need a data warehouse here for the scale that we were doing. We couldn’t do flat files forever– that wasn’t going to go well. So we looked down our Backlog and we said, “At what point do we start requiring that kind of infrastructure instead of building it first, we’re going to earn it with functionality.” And we slowly built that as we were also building features.
But by the time we got into it, we knew so much more about the shape of the data and the kinds of things that the people were doing with it. So we ended up building a much better data warehouse. It wasn’t just abstract analysis, it was the real thing.
So I read an article recently about how to think about this sort of thing. When you have things that you feel like you need to do first before you can start, and you want to take this kind of approach where you can, here’s the way to think about it. There’s three kinds of infrastructure work or foundational work or enabling work or whatever your team’s word is for it. There are things where you would say like category one, we can’t start producing value without it.
Like our team doesn’t have computers to work on. That’s a category one thing. We can’t build the smallest slice of value without having that. Category two is we need it for the very first increment of value. So this is kind of the most basic technology stuff like we need to install the programming language that we work on and have some basic development server or something.
Category three is we eventually need it to achieve our vision.
And the big mistake that most teams make is assuming it’s all category one, when in reality it’s mostly category three.
We assume we need it all before we can start, when most of it is, our intuition is probably right. We do need some of these things, but we can grow them as we go.
So that article I link to talks through how do you think about those three categories and what do you do with the things in them? But the key principle here when it comes to avoiding this mistake of allowing technical dependencies to take over is having a bias towards delivering value and going straight towards the core complexity of whatever you’re doing. And any time something comes up where it’s, “Well, we should just do this thing,” or “We have to do this before we can do something else,” be suspicious about that and ask “How could we get to the value of more directly, sooner?”
I didn’t have it at the time when we did the wastewater thing, but what I realize in retrospect is we were doing feature mining, which is the technique we teach in the Product Owner class or 8020 Backlog refinement class, where we’re looking for what is that quick win, if you like, that actually goes after the core complexity, which is really what that dead simple flat file data warehouse and reporting system was– that was a quick win. In fact, it was a really valuable win, but it was a quick win through the core complexity of this thing rather than just, “Look, we have some data and we can’t do anything with it.” That’s not really a quick win.
So that’s mistake number four. Let’s get to our last mistake.
Too many people make good Backlog refinement, which is acceptance criteria as a contract.
Go back to the Agile Manifesto. One of the values is customer collaboration over contract negotiation and then what you see in practice, we have to nail down all the details during Backlog refinement because we don’t want things to change during a Sprint or team member saying you didn’t put that in the Backlog, that wasn’t in the story. I’m not going to do that, which is to say we’re treating acceptance criteria as a contract.
The bad news is that for complex, meaningful work, the details will necessarily change as you do the work. Emergence is just an inherent part of creating new things. So not only does trying to escape that harsh reality not work, you’ll still encounter all the change you’re trying to avoid; the illusion of certainty will cause you to experience the change later than you have to, and it’s going to feel like waste and rework and frustration.
So instead, try to capture enough detail to start, but not enough detail to finish, building the expectation that you’re going to collaborate as details emerge. And I wasn’t planning on saying this, but since Pam brought it up earlier, one of my favorite ways to structure that collaboration is around concrete examples, and that’s really what behavior driven development is about.
And you can ignore the cucumber part if you want, which is turning those examples into automated tests. But one of the best ways to get just enough alignment to start, instead of trying to do abstract acceptance criteria, tell stories about examples, which is really what we were doing when we asked those engineers, “What is the question you’re trying to answer?” And then “tell me more about that. What’s a different example? How did that show up in the last plant you were in?” And all of that was just really exploring a concrete example to use that to try to understand what we were trying to build. And we didn’t have a lot of details. And I think the system shall have this data with all these fields and here’s what we’re going to do with them.
And the report is going to look exactly like this. We had some examples of them answering the question, and then we collaborated with them to figure out exactly how the product should work. So build this into your work. Just enough information to start, but not enough to finish.
So we’ve talked about some of these common Backlog refinement mistakes. And before we kind of wrap up me talking and go to some Q&A with our remaining time, I want to pull all of this together by flipping the focus from the mistakes to casting a vision for what healthy Backlog refinement can look like.
So I invite you to picture the sort of opposite of what we have been talking about, and let me describe that. So picture this: Your Backlog is shaped so that the most detailed items are at the top and there’s less and less detail as you go down the Backlog because of course, you know less about the future than you do about the short term. That Backlog is modeled as a Kanban board with Work In Progress limits for every level of granularity. So if you have two Sprints of User Stories ready to go, you feel no pressure to make more stories.
You don’t have that many items to pay attention to. In fact, we like 6 to 10 stories in a sprint. So if you have one team that you have pulling from your Backlog, that’s like 12 to 20 stories at the top of your Backlog, not very much. Every day you start at the right side of your board and you ask yourself, what do I need to do to keep the items in this column moving?
And you do that column by column moving to the left until you run out of time, and then you go to the Italian happy hour with your team or go home or whatever it is that you do.
As a Product Owner, you join your team’s daily stand up. You’re ready to keep them unstuck on in-progress items, and you’re prepared to ask for their help on incremental refinement on the items to the left of the board. Like I’ve got this new story. I think it’s too big. Who can spend some time talking with me about it today? When you get to the end of your day, not everything’s refined.
You didn’t get all the way left that day, but you feel good about your work because you know, all the short term refinement’s taken care of and you’ll have more time tomorrow to work further to the left on the board. Every day looks like this. A little more refinement, but just enough, just in time. No more huge Backlogs. Two years in the future, no more churn and rework, No stress leading up to Sprint planning, No three hour refinement meetings every week that nobody enjoys. Just calm daily progress.
What questions do you have?
Peter
Thanks for tuning in to this week’s Humanizing Work Show. We don’t rebroadcast the Q&A sections of these community sessions, to keep things private for community members. If you want to participate live in future sessions, sign up at meetup.com/humanizingwork/ and we’ll drop that link in the show notes.
If you like the Humanizing Work Show, the best thing you can do is subscribe to the show on your podcast app or on Youtube, leave a review and a comment, and of course share links to specific episodes that you found helpful on your social media accounts. You can also send us questions you want us to answer or episode ideas to mailbag@humanizingwork.com, and you can subscribe to our newsletter in the footer of any page over at humanizingwork.com to get more free weekly content from us. Thanks for tuning in.
Last updated