In my experience, any job you want a sprint goal to do for you can be done better by a well-structured product backlog and good conversations around it.
In this episode, Richard and Peter talk about sprint goals. When are they useful? What might you do instead?
Learn More
Certified Scrum Product Owner Training (virtual, instructor-led)
Advanced Certified Scrum Product Owner Training (virtual, instructor-led)
2-Week Backlog Makeover Course (online, self-guided)
80/20 Product Ownership Course (online, self-guided)
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work mailbag, where we answer questions from the humanizing work community. Today we’re talking Sprint goals. What are they for? Do you need one on your team?
Peter Green
Before we jump into today’s episode. We want to help you with whatever challenges are most frustrating you right now. If you’re feeling stuck on something, whether that’s trying to take a more human centric approach to your work, trying to make your product or business outcomes better, or if you’ve just got a more tactical process related question, let us know about it.
Send us an email at Mailbag at humanizingwork.com with a few details about your situation, and we’ll share how we might think through that challenge right here on the humanizing work show.
Richard
And just a quick reminder, please rate and review the humanizing work show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable. Your help in spreading the word about the show is super meaningful to us.
Peter
If you want to get access to more of the content we produce, not just the show, then you can subscribe to our newsletter where we share one key idea every week.
Sign up at Subscribe – Humanizing Work
All right, This is a question that came up in both of our classes this week. I’m teaching a certified Scrum Master class. Richard is teaching a certified Scrum Product Owner class. And it’s a question we get pretty commonly. So we thought we’d address it since it came up in both of those contexts today. And the question is, “Do we really need a Sprint goal?”
Richard
It’s a good question; and before we get to our opinion about that and what has worked for us, let’s start with the official definition of Scrum. So what are Sprint goals designed to do per the Scrum guide? I’m going to read the section about the Sprint goal here. It says,
“The Sprint goal is the single objective for the Sprint. Although the Sprint goal is a commitment by the developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint goal also creates coherence and focus, encouraging the Scrum team to work together rather than on separate initiatives. The Sprint goal is created during the Sprint planning event and then added to the Sprint Backlog. As the developers work during the Sprint, they keep the Sprint goal in mind. If the work turns out to be different than they expected, they collaborate with the product owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint goal.”
Peter
Nicely read, Richard. All right, so that’s kind of the official word from the authors of Scrum, from Ken and Jeff. And as I listened to you read that, it kept striking me that this is kind of odd. The Product Owner is accountable for what the team works on. They should be capturing that in the Sprint Backlog. And so there’s some– I don’t know– almost a lack of coherence for me with how they’re describing the Sprint goal, what it is supposed to do.
But on the other hand, like when we adopted Scrum, we found Sprint goals to be occasionally very helpful. For example, when we first adopted Scrum, this was going back 18 years now, but going back to 2005, we were coming from a world where we did pretty detailed product specifications. We had a product requirements document, there were a whole bunch of features to build, and we were trying to shift our approach into this much more iterative thing that was Scrum.
And so I remember in our very first Sprint we were trying to figure out, well, what could we possibly ship in a Sprint? What could we get all the way to releasable in a single Sprint? Because our team was used to working in what would have been like 20 months of effort to get a product out the door.
So what could we possibly get all the way to Done in a single Sprint? And just that question, like “what could our Sprint goal be?” caused us to think differently about how we structure the work. And that first Sprint I remember was “open and play back an audio file.” We were building a 1-0 audio application and so we thought, okay, that’s probably small enough that we could get that done in a single sprint and all the way tested and releasable.
And it would give us a lot of technical validation for what we’re doing. That was a useful Sprint goal for us because it caused us to structure the Product Backlog in a certain way. I remember a couple of Sprints later it was “display a waveform,” which is like the little zig zag line that you might see. You see those on social media when people are sharing their podcast clips all the time, but that waveform represents the audio file.
And so we had a whole bunch of little features related to that: “display, a waveform,” like zooming in and out and you know, how is it shaped and the nuances of it. But the overall goal of “display a waveform.” That was the thing that was actually useful to us. And then very frequently we would find that there were three or four high priority things that we wanted to get done in a Sprint.
There wasn’t a really obvious connection between those three or four things. They were all important and the Product Owner was able to make the case: This one’s important for this reason. This other thing that’s not like clearly related to that is also important. I mean, they’re all part of the same product. So I guess we could have said “Our sprint goal is “do the highest priority items on the Product Backlog because they’re all equal.”
You know, they’re all important in the order that they list right now. But that didn’t seem like aligned with the vision of what a Sprint goal is. And so we always felt a little bit guilty when we had those. “I don’t know. I guess this is the Sprint goal?” And other times it’s like the thing at the top of the backlog is already the Sprint goal.
Why do we need to restate it in some way and why do we need to wait until the Sprint planning event to do it? And the developers are coming up with it and putting in the Sprint Backlog. It just felt kind of awkward to me. So I’ve seen some cases where it was helpful kind of as a bridge from a big bang, large release approach, helped us get into the thinking of, well, what if we split it down? But most of the time I just feel like it was added weight that really wasn’t that helpful in hindsight.
Richard
Yeah. And I go even further. I almost never recommend a team use a Sprint goal because in my experience, any job you want a Sprint goal to do for you can be done better by a well-structured Product Backlog and good conversations around it.
if the point of it is to provide some larger meaning to the small Backlog items we’re working on, our Backlog should probably reflect that. And if you listen to our episode about the PO board or why we don’t like epics, you heard us talk about Minimum Marketable Features. MMF’s, minimum marketable features, are these increments of value that are big enough that they’re actually marketable, they’re worth shipping, they might fit in a Sprint, they might span a Sprint, but it really is enough value that we actually would ship this thing.
And then smaller Backlog items, often user stories would build up to that. And so what’s the Sprint goal? “Complete the user stories that build up to the Minimum Marketable Features that are at the top of our Backlog” and we should be aligned around why those things are important. So adding another layer of a goal around it doesn’t really make sense if the Product Wwner is doing their job well.
So I generally don’t recommend them. If you find yourself using them, it’s probably a signal they work more on your Backlog. And that’s what I heard in your story, Peter, about the Audition team. You were essentially coming up with MMFs; You were just doing it, you know, intentionally coming up with a sprint- sized MMF rather than a natural market driven MMF That may or may not fit exactly one Sprint.
Peter
Yeah, that’s right. The actual MMF on that first team was “edit an audio file.”
Like that’s the thing that people actually would pay to have our product do for them. So “open and play playback an audio file,” I mean, really that’s not marketable. Look, now you can play back audio on a computer. Fascinating, right? It wasn’t it. So wasn’t until you can actually edit it, that it’s useful; and then– so yeah it really was not a full MMF, but it helped us get there eventually.
And it wasn’t really until like Sprint nine where we started getting better at MMF’s. Multiple slices within those MMF’s. And that’s now that I think about it also about when we stopped worrying about Sprint goals, right? So once the backlog was reflecting value and impact and then slicing that into those thin user stories, we just stopped seeing the usefulness of it.
And so maybe that’s a pattern that some of our listeners will also discover– is that maybe it’s a bridge into thinking about the Product Backlog differently. And once you get there, you don’t really need them anymore. I think, you know, the intent of this is we want work to matter. If I’m on a team and I’m building something, I want to understand why the thing I’m working on today matters.
Who’s it for, what impact does it have? And so all of the things that great Product Owners are doing should be answering that question and probably even better than a Sprint goal. Like not only what’s the overarching goal for this Sprint, but this little slice of it that’s going to take just a few days for our team to knock out, how does this build up to bigger impact and how does it give us a way to test that impact early? All of those things really should do that job. And so I think the Sprint goal idea is trying to solve a real problem for Scrum teams, but it’s not the solution I’d pick.
Richard
Did you find this useful? Please like and share the episode and keep the questions coming. We love digging into tough topics and interesting questions, so send them our way.
Last updated