It’s simultaneously high leverage–if you get this right, all the parts of an agile approach just seem to work–and you can go from zero to fluent in skills like story splitting with a few hours of practice, which is like almost no other skill we use in our work. Zero to fluent in that short amount of time is pretty stunning.
In this episode, Richard and Peter talk about the business case for getting better at product backlog refinement. What’s the financial and human cost of bad backlogs? Way more than most people realize. Here’s why it matters and what to do about it.
Learn More
Introducing 80/20 Product Backlog Refinement, a new course from Humanizing Work designed for Product Owners, Managers, and anyone steering the direction of a product. This self-paced program is your key to mastering essential skills that will maximize impact, minimize risk, and propel your product and team to new heights.
Episode Transcription
Peter Green
In my role as the Agile Transformation Leader at Adobe from 2008 until 2015, and then as an independent trainer and coach after that, I used to challenge anyone to show me a feature or a project that was unsplittable. People would describe their trickiest, most complex things, and then we’d proceed to split it together. In 15 years of throwing down that challenge, I only had one example of a thing I couldn’t split down into several small slices, small enough to get several of them done in a single Sprint. But I was doing it very intuitively. I couldn’t put my finger on the patterns I was using to split those items. All I could do was confidently say that anything could be split smaller, and then prove it.
Then when Richard and I first met, I found a kindred spirit. I learned that he often threw down the same gauntlet. But what’s so cool about Richard Lawrence is that he’s great at figuring out the patterns behind things, and then describing them very succinctly. And he’s done that with splitting big things down into smaller slices. The first public example of that is his well-known Story Splitting Cheat Sheet.
Richard
And, before that, it was the article that became the cheat sheet, and the back story there is interesting. I wrote this article in 2007, on patterns for splitting user stories, and at the time, it was just “Here are some things that seem to be working for my team; maybe they’ll be useful to somebody else.” I didn’t think much of it. And I put that out on the internet, with that challenge at the end, like “I don’t believe there are any unsplittable software stories. If you think you have one, bring it to me.” And I was hoping to learn some things from that and have people bring me the hard ones, and maybe I missed a pattern or something. Well, after a few years of responding to people saying “Here’s the thing I’m struggling to split. I’m not sure it’s splittable,” I found that I was asking the same sequence of questions over and over again, and so that well known story splitting cheat sheet or flow chart or poster or whatever you call it, that’s now translated into all those different languages, is our number one download. That thing was initially just, “Here’s the series of questions I ask when I’m helping walk somebody through, teaching this, and I found it’s pretty reliable at producing the outcome of small slices you could pull into a single Sprint.”
Peter
And then, after the story splitting poster, the next big tool that I became aware of was feature mining which is a technique to collaboratively find the first slice in a big idea, and then many additional tools that enhance all these capabilities. And the patterns that Richard made visible helped me understand what I was doing intuitively, which of course makes it something that can be taught.
Prior to that, I could only prove that everything is splitable by demonstrating it. It was almost like performance art. You give the monkey a story and I will dance and I’ll split it for you. But that doesn’t help people do it themselves. So after teaching these techniques to Product Owners, they can split anything. So these tools are really helpful for teaching anyone to do it.
And then we find that a lot of Product Owners end up teaching their teams to do it as well. So then it’s no longer just the Product Owner doing all of the splitting. It’s a collaborative activity and that makes both the PO’s life more manageable and leads to better outcomes since you have multiple ideas coming from different team members’ perspectives on how to split.
Richard
Yeah, I think it actually has to be collaborative and because usually the Product Owner understands the problem side of things really well but isn’t as deep in the solution side of things and vice versa in the development team. And putting those two perspectives together is where you find the really good slices.
Peter
Yeah.
Richard
So in 2015 I built out an online course to walk through feature mining and story splitting to try to scale this. So it wasn’t just people who had direct time with me who could benefit from learning these things, now that they were pretty reliable. That one, 80/20 Product Ownership, has regularly been the best-selling online course we offer over at learning.humanizingwork.com.
Even eight years later, it still sell strong. But in those eight years, we’ve continued to get clearer about the underlying patterns and how to teach them and what additional techniques Product Owners need in order to split things as easily as we were doing it intuitively.
Peter
And so for the last year, we’ve been working to create a major rewrite of that course, and we’re about to launch the brand new course called 80/20 product Backlog Refinement. We’ve been testing this with a group of Product Owners from masters and Coaches for a couple of months because we’re good Agilists, we want to give a little small slice to somebody, get some feedback on it, improve it based on their feedback, and we’re really excited to share the results of that with everybody.
We think that pretty much everyone can benefit from figuring out how to take big, challenging things and split them down into small slices of learning and value. I was having a conversation with my brother a little while ago and he plays a product on a role at a large medical company, and I mentioned that we were working on this course and what we were going to call it a20 product Backlog Refinement, and he sort of rolled his eyes and groaned a little bit.
And I said, “Well, what’s wrong with that?” And he said that for them, Backlog Refinement is like this weekly full team bureaucratic debate about pointing and tasking and arguing about priority and dependencies. And for him, the term backlog, refinement just calls to mind red tape, busywork, bureaucracy, kind of ineffectiveness and no one on the team looks forward to it, which is tragic to me because when it’s done right, I love doing this kind of work.
I find it creative, fulfilling, very purposeful, and we think everyone listening would benefit from getting better at Product Backlog Refinement. Even if you don’t call your list of work a product backlog. People that are not in Product Owner roles, people that are outside of software, outside of the Agile space, we all have big goals that would benefit from slicing them into small slices that build some momentum, some learning and some value really quickly.
Like I’ve used the techniques from this course to do things like buying a house and moving, going on vacation, planning and launching a new youth program. But we’ve never really talked much about the business case for why slice this way. So if you’re not sure why improving your skills at Backlog Refinement might be useful in this episode, we’re going to make our case.
And if you already know that you want it, you want these skills, but you might need to convince someone else who might hold the budget strings to buy a course like 80/20 Product Backlog Refinement. You can use the points that we make in this episode as talking points. So let’s start with this, Richard. What do you think most people get wrong related to Product Backlog Refinement?
Richard
Well, similar to what your brother said, I think there’s this popular myth that Backlog Refinement is just managing JIRA tickets and arguing about tasks and estimates, and it’s like admin work around a backlog. But in reality, better Backlog Refinement I think is one of the best levers you have for a return on your biggest investment, which is the staffing cost of your team.
Peter
Say more about what you mean by better Backlog Refinement.
Richard
Yeah, I think of three things when I think about better Backlog Refinement, like good Backlog Refinement does three things. It’s, one, reliably getting the right things at the right places in the backlog, especially the most important things at the top. But even thinking about things like the relationship between time and value and sequencing things that will be really valuable later at the appropriate spot where you can experience that value.
Number two, good Backlog Refinement is always having just enough detail at the right time. So neither too much too early, which causes churn nor too little too late, which causes scrambling and rework when you try to plan. And then, three, good Backlog Refinement means alignment among everybody involved so that everyone knows how to contribute and build the right thing and go in the same direction.
Peter
I think those are all things that most Product Owners seek for. They would love to have backlogs that reflect those qualities. What do you see most often when you’re encountering a Product Owner for the first time or like what’s kind of the state of the industry of Product Ownership as it relates to Backlog Refinement?
Richard
Most Product Owners that I interact with have really long lists of things that are too detailed for how far out they are in the future, but not detailed enough that somebody could just go work on them, it’s like simultaneously too much detail and too little detail. They’re usually not very strategic. It’s just the grab bag of everything everybody has thought of stuffed into a tool where it’s hard to manage.
And so a lot of Product Owners I talk with tell me they don’t feel like they have enough time to really collaborate with their team on the short term work, and they don’t have enough time to get strategic about what’s going on in the long term. They’re just stuck in this messy middle where they’re not experiencing anything really good there and they also don’t have time to go do some of the other things that are not Backlog Refinement, like customer research and product assumption testing and vision and all those things that sit around content like this.
Peter
Yeah. It reminds me, one of the teams that I had a really good experience working with at Adobe was the team that used to build the tool called Flash Professional, which is like a flash authoring tool. Back when Flash ruled the world– at least the web. And so they built the tool. Yeah, they built the tool, right?
And when they adopted Scrum, they did a really, really nice job of it. And did some really interesting things involving things like the customer advisory board showing up to every Sprint review where they demoed the build that Sprint: some cool stuff. And Doug Benson, who was the director of engineering over that team. I remember seeing him in the cafeteria a couple of years after I had worked with them and we just kind of sat down and had lunch together and were catching up.
And I said, “So it’s been a couple of years. What’s changed?” Like I always wonder when I’ve worked with a team that I don’t see for a while. “Did any of that stick? Was it useful?” And so I asked Doug a question, something like “What’s been the biggest benefit of taking a more Agile approach?” And he said by far the biggest benefit is we no longer write really detailed specifications for features we’re never going to get around to building. And because we build little slices, we no longer build things that our customers don’t want. And I think those are the real business outcomes from better slicing. You don’t over specify and you don’t worry about writing a bunch of features that nobody’s ever going to want.
What led you to focusing so much of your time on this topic of Backlog Refinement? Because that’s not where you started. You started out as a developer doing extreme programing, which is a pretty kind of technically focused approach to software, and I’m wondering how that turned into being the guru of all things splitting.
Richard
If we go way back when I started with extreme programing, I think I got decent Product Management for free on some of those early teams. And so I focused a lot on getting teams collaborating well and building good quality. And then a few years into it, I remember one team I was working with, we went from struggling to delivering reliably in weekly Sprints after about six weeks and then looked around and realized nobody wanted the thing we were building.
And that was the point where I realized first off, that this Product Management thing or Product Ownership or whatever you call it in your context is a prerequisite to everything else. It doesn’t matter how good your developers are, if they’re building the wrong thing or don’t have a valuable thing to build. So that was where I started looking seriously at how to do this well.
And then once I started doing that, I found that one of the big skills that people struggle with is taking big things and breaking them down into smaller things that will actually provide meaningful value and learning and risk mitigation as you go. And that’s what led to the story splitting content. And like I said, that was really something I just did for my own team and put out there and didn’t think it was a big deal.
And then the response to it was overwhelming. I realized people everywhere are struggling with that skill and it’s a very learnable skill. So that was the other thing that made me focus so much of my career on Product Ownership. It’s simultaneously high leverage. If you get this right, all the other stuff in an agile approach works or vice versa, and you can go from zero to fluent in skills like story splitting with a few hours of practice, which is like almost no other skills we use in our work.
That “zero to fluent” in that short of time is pretty stunning.
Peter
Yeah. So we mentioned the benefits to a Product Owner and to their team that it almost certainly leads to Agile starts to just magically work, which was the experience we had. It took us eight Sprints of sort of doing things a more traditional way with kind of more detailed feature specs and then things not working during the Sprint or particularly leading up to the Sprint review and then finally realizing, Oh! If we split things down into like maybe eight or ten things in a Sprint instead of two, suddenly all this agile stuff starts working.
So that’s been a clear benefit that we’ve seen over and over is that Agile starts to make sense and you start to realize why Agile might be a good thing to do and how to make it work when you get these smaller slices. And we sort of alluded to (per Doug’s comment to me) that we no longer build features that our customers don’t want and we no longer waste time writing specs for features we’ll never build, that alludes to a business benefit here. And so I’m curious if you’ve thought about the business case for this, like if somebody wanted you to make it, put it in financial terms, economic terms, like I remember doing the math when I was at Adobe. On what it cost for a single team to do a two-week Sprint.
This kind of fully loaded cost of those employees. And it was a six-figure number.
Richard
Yeah, I don’t think people realize how big the numbers are when you have a whole team of professionals and all the salary and benefits and tools and office and all the different things that you’re paying for. The quick back of the napkin version of this I use when we can’t actually calculate it is about $1,000 per person per day fully loaded cost for a software developer type professional in the U.S. So your team of seven people, the typical Scrum team, is $7,000 per day or $70,000 for a two week Sprint.
Now you go to an expensive area like Seattle or the Bay Area or something like your team in Adobe, and the numbers are going to be even bigger, a bigger team, the numbers are going to be even bigger. And if you go back to the three criteria I mentioned earlier, for a good well-refined backlog, we’re focusing on the most important things, we have the right detail at the right time and we’re aligned around what it is and what it means. That is going to be the number one thing that determines the return on your investment. Good value represented in your backlog makes it most likely you’re going to get something valuable out the other end and if you’re backlog is not in good shape, you can have a $100,000 Sprint worth of investment going in the wrong direction or floundering or reworking things that they misunderstood and did wrong.
So in terms of the return on investment on this, if a Product Owner spends, you know, a few hundred dollars on a course like this one that we’re talking about, 80/20 Product Backlog Refinement, and spends half a day to a day practicing with the things that they’re learning, that could pay for itself in one Sprint. If a team goes from you know, one day they would have struggled or worked on the wrong thing and now they’re working on the right thing, you just got a 200% or more return on investment on that one thing.
Peter
And that’s just a loaded cost. So I was thinking about when you were telling your story about, you know, you spent how many Sprints on that XP project building the wrong thing. How many Sprints was that?
Richard
All right, six weeks.
Peter
Six weeks. So I don’t talk about this very often, but the original product that we introduced Scrum, was called Adobe Sound Booth. And I don’t talk about that because Adobe Sound Booth lasted for two versions before the company killed it. It’s the same team that made Audition. So when I refer to it now, just so people know what I’m talking about, I always talk about the Audition team, but we actually built a product that was going after a different target market.
It was an experiment. It was “We think these people could use this thing. Let’s build this product and see if it’s true.” And then it turns out after that first major release, we already had data that was like, no, those people don’t want this thing that we thought they wanted. And then we ended up killing that and building those capabilities back into Audition because that’s what they actually wanted.
It took us a few years to learn that, and I’ve always thought about that kind of with a little bit of guilt, like, shouldn’t we have known that sooner? But around that same time, it usually took, for Adobe to launch a new product from idea to launch, three or four or five years. We launched it in 18 months. And so even though I wish we had gotten that feedback earlier, we got it way earlier than we normally would have. So another way to think about this is the opportunity cost. How long are we devoting this team’s focus to the wrong thing before we know it’s the wrong thing? And for us, because of the sort of constraints we were under, it was 18 months before we started getting evidence that this was the wrong thing to build. For your team it was six weeks. And now for teams that are able to deliver even more frequently and then get feedback on it, that benefit could be pivoting off something that would have wasted Sprints and Sprints of time and effort. So I think there’s a huge opportunity cost option here that if you’re not only using these splitting techniques, but then thinking about how you’re getting feedback from the market on those slices you’re building, there’s a huge potential benefit here.
Richard
Yeah, when I did that back of the napkin math, I was assuming that the things in your backlog are at least break even for your team, but hopefully the things in your backlog are worth substantially more than your team costs. And so having your team focusing on the valuable ones rather than the break-even or worse ones is an even bigger ROI.
Peter
So the new 80/20 course, it’s a couple hundred bucks, takes a few hours. I’ve heard you say that you can split anything. I’m curious, what’s the first slice of learning about 80/20? If you were to take the course itself and say you should only focus on one lesson, what’s the 80/20 lesson within the new course?
Richard
I think it depends on you and what the constraint is for your team. But I can mention a couple of my favorite lessons in the course that tend to be particularly high leverage for most of our clients. Feature mining is still one of the favorite things for me. Out of all the different things that we teach, it reliably gets you from “I’ve got this big, complex idea and I don’t know how to start,” to “Okay, here’s the first slice we’re going to do,” and being able to find that first slice tends to get you some momentum that makes everything else work after that. So if you don’t already know feature mining, that’s probably a high leverage point for you. The other one that I think is interesting and will help a lot of people is what’s almost an introductory lesson in the course where we talk about how slicing skills are the breakthrough solution to prioritization.
Almost every Product Owner I talk with complains about pain around prioritization, and I’ve become convinced that the prioritization problem isn’t really a ranking problem. Like people try to solve it with spreadsheets and calculations like weigh the shortest job first or something. And I don’t think that’s the way out of it. I think slicing skills sidestep most of the pain that people experience around prioritization and that short video might unlock something for somebody getting started with the course right away and then of course the PMO board, which we’ve done an episode about, but I go into more depth in the course, which is a way of structuring your backlog to turn Backlog Refinement into a calm, sustainable thing instead of, like your brother experiences, a weekly meeting that nobody wants to go to. I don’t think Backlog Refinement should mostly be a recurring all team meeting, right? I think it’s just the work of the Product Owner in collaboration with other people as needed.
Peter
The other one that I thought you might mention is as we get into deep dives on each of the patterns from that story splitting cheat sheet, there is one lesson where we’re talking about workflows, how to split workflows. But what we’ve uncovered over the last few years is that hiding underneath the workflow splitting pattern is actually the meta pattern.
Like there is sort of a meta pattern underneath all of them that we first kind of realized as we were describing splitting workflows. But then as you go and look back at the other patterns, it’s actually the pattern that underlies them all. And so I think that there’s a real 80/20 slice there where if you just understood the meta pattern, that’s the 80/20 slice of the story splitting– how to split a user story. It’s very meta.
It’s the meta of the slicing, it’s the thin slice.
Richard
It’s the one I actually use. When I’m splitting things and not thinking about the list of patterns on the poster, hose, it turns out, are all concrete expressions of this, right?
Peter
So we’ve sort of tried to make the business case from a few different angles here and these are the things that we firmly believe that if you can apply these skills and you can get a team that’s stuck on something because they didn’t split it well or they’re working on the wrong thing, even if it’s just a little piece of the wrong thing and they’re wasting thousands of dollars a day.
And so we could charge thousands of dollars for this course and people would still get a positive return. Of course, we’re not. As I mentioned, we’re just charging a couple hundred bucks for it. Far less than the benefit you’ll get from it. And so if you want to learn more about this, you can go to humanizingwork.com/8020 and read more about the course.
And we hope to see a lot of you in there and we hope that you can get the benefit from splitting and from better Backlog Refinement that we’ve seen over the years that we’ve been practicing these techniques both on our own stuff as well as with our clients. So thanks for tuning in today and we hope to see you back soon.
Last updated