Every commitment carries the risk of circumstances changing, so lets agree ahead of time about what we’ll do if and when conditions change.
Scrum’s rarely used “Abnormal Sprint Termination” rule can help a team strike a nice balance between the need to focus, the need to be responsive, and the desire to make and keep commitments. In this episode, we give a few examples of using this rule to get good results, and what to do if your team is struggling to make and keep commitments.
- Humanizing Work Show Episode: The Healthy Way To Do Commitments & Accountability
- Humanizing Work Show Episode: I Can’t Get My Team to Collaborate
- Certified ScrumMaster Workshop (virtual, instructor-led)
- Certified Scrum Product Owner Workshop (virtual, instructor-led)
There’s this rarely used rule in Scrum about “abnormal Sprint termination.” It can teach us some things about how we balance focus and responsiveness and how we make, keep, and renegotiate commitments, in Scrum and beyond. Peter, I’ve heard you tell a story about a sprint termination on your team at Adobe.
Ya, this story requires just a little bit of back story to understand the story.
The back story of this is that before our team adopted Scrum, we had been a startup that was acquired by Adobe, and in the first few years of our work at Adobe, we did a lot of things to make the application– Adobe Audition– look like other apps. So we had rewritten the entire front end and a big part of that effort was just taking an existing window in what had, before that, been called Cool Edit Pro and kind of porting it to this new UI framework, so it kind of had a look and feel of other Adobe apps. And so we had this long list of windows to port to the new UI framework. And as we did that, there was also some cleanup we had to do because Cool Edit had started as a shareware app where David, the original author of the program, had sort of, you know, built out windows as customers asked for things.
And so there was a little bit of, kind of, overlap in some of the functionality. And of the two windows that had a lot of overlap, one was called the Play List Window; one was called the Cue List Window. And radio stations would use those to kind of load up a sequence of audio files like the bumper music; the news; the song; the deejay commentary; that had been pre recorded– and then they could kind of hit play and it would just kind of go through those things. And I don’t remember which one was which, but one of them was kind of a subset of the other. So the Cue List window and the Play List window kind of did similar things. And so as we were porting all of these windows over, we realized, “Why are we going to spend the effort to port both of these? They kind of do the same thing. Let’s check with our beta testers, our community, and say, ‘Which one do you use more often?’” And then we’re going to cut the other.
So we did that. We saved probably, I don’t know, three or four days porting a window in Audition 2.0. After Audition 2 we adopted Scrum and when we adopted Scrum we agreed as a team that we were going to try and use Scrum by the book for at least one full release, figuring there are going to be parts of this that are hard that we won’t really understand until we practice them and see how they work for our team.
So we start using Scrum and we’re in our second sprint and we have just released Audition 2 into the world. So we’re in Sprint 2 and Hart, who is our product owner, gets a call from his contact at– well, I’ll just say a very large UK based media company that had hundreds, maybe thousands of radio stations, TV stations. They use Audition a lot, and it was one of our biggest customers. So we’ll call him Ian. This contact from this company phones up Hart one day– our Product Owner– and says, “Hart, we just got our evaluation copy of Audition 2.0. We love the new UI– love all these new features. This looks really great, but what happened to the Cue List window?
And Heart says, “Cue List window… yeah, we cut that. Yeah, Well, you can do all the things that you used to be able to do in the Cue List window using the Play List. The Play List is, you know, more feature rich. If you want to pop open Audition, I’ll walk you through how to use it.”
And Ian says, “Yeah, yeah, yeah, I know all about that. But years ago when we were automating how we send audio around our radio stations, we wrote some hard coded automation script in some ancient language for our mainframe system that is calling out specifically “Cue List. It’s looking for the Cue List window and our automation is now failing on Audition 2. We basically can’t run our radio stations using Audition 2.”
So Hart’s head is exploding, right? He’s made forecasts– revenue forecasts based on assuming we’re going to keep this client– maybe even get more seats from him. And so he pulls up the old feature database and he sees that to port that window was only going to take us three days. And so Hart being the wise business person that he is, says “Ian, what if we were to do a private branded version of Audition 2 just for your company, your edition? And it has that window in it, and we even put your name on the splash screen. And would you upgrade to Audition 2?”
And he says, “Of course, like we love the new product, we just need that window in there so that the mainframe doesn’t fail.”
And Hart looks at that estimate, and says, “No problem, we’ll get you that in a week–we’ll get you your own version of Audition 2 in a week,” hangs up the phone, runs down the office to Todd’s office, who is our head UI developer, and says, “Todd, we’ve got this big issue with Audition 2, We really need you to port this one window.”
Todd pulls it up and says, “I have ported dozens of these windows. I don’t even think it’ll take me three days.” He gets going on it the next morning. At the Daily Scrum, Todd comes in and says, “Hey, I was working on the zoom control for the waveform in the next version, but we need to do this special version of Audition 2 for this customer, and I’ll probably need some testing help– Charles, can you help with testing that?”
And as a new Scrum master, I’m kind of freaking out because in Scrum there’s this rule, kind of a bi-directional agreement, that when we pull, like when the developers pull work into the Sprint, we’re committing to do everything we can to get that done. And the Product Owner is making a commitment to allow the developers to focus on that by not inserting new work into the Sprint that they hadn’t already pulled in during Sprint planning.
And I was remembering that conversation we had, about, “Hey, we’re going to try Scrum by the book at least for one release,” and now it’s Sprint number two and we’re already about to break that commitment because we’re breaking a huge Scrum rule here. And so right after the Daily Scrum, I walk down to Hart’s Office. Hart is and was a great friend.
So instead of going in and saying, “Hart, what’s up?” I remembered that in my training, one of the jobs of the Scrum Master is to educate the organization about the rules of Scrum and why we might want to follow them. So I walked in, knocked on the door, sat down, said, “Well, hello, Mr. Product Owner, I understand you have inserted new functionality in the middle of Sprint two” and Hart kind of looked puzzled for a moment and then said, “Oh, you mean that special build of Audition 2: Yeah, yeah, yeah, we got to do that.”
And I said, “Yeah, I remember when we agreed that we’re going to follow the rules of Scrum for one release.”
And he said, “Yeah, I remember the agreement. So what? Should I call Ian back and say, ‘Sorry, Ian, we can’t do that special build of Audition because we use Scrum’? That doesn’t seem like a good business choice.”
So I said, “Yeah, I agree.”
And he said, “So what are my options according to the rules of Scrum?”
And I said, “Well, you kind of have two options in this situation. Number one, you’re the Product Owner. You could take that special build of Audition to put it at the very top of the Product Backlog, which means a week from now, when we finish this Sprint, the team can pull that in first. Todd and Charles will knock that thing out in a couple of days. So maybe two, three weeks from now you could get that private build of Audition over. That’s one option.”
Hart said. “Well, I told them a week. Now you’re telling two or three. I don’t know if I like that. What’s the other option?” I said, “Well, there’s this thing called the “abnormal Sprint termination” where some new information has come in that’s so important that we’re going to cancel the current sprint.”
And he said, “Well, what does it mean to cancel the Sprint?”
I said, “Well, essentially we get the team together. We say, ‘Hey, this thing has happened.’” We’re transparent about it. We officially are canceling the Sprint, which means as a Product Owner, I’m releasing you from the commitment you made for what you said you would do in this Sprint and kind of bi- directionally releasing each other; not Hart saying, “I need to change my commitment as well because I need this new functionality.”
So he said, “So basically we get in the conference room and have a meeting?”
I said, “Yeah, but then at least we can kind of honorably release each other from the commitments and then the team will pull that in and we’ll re-plan the Sprint based on that. That allows the team to decide if we pull this in, what needs to come off, what could we still get done.”
And Hart said, “Well, that sounds like a lot of hassle. Let me check with Ian.” And he calls Ian back up. And he says, “Hey, Ian, (I think he may have blamed the team) the team’s telling me that the private build might take a little bit longer, maybe three weeks. Would you still buy Audition? Will you still upgrade?”
And Ian said, “Oh, yeah, we actually weren’t going to make a purchase decision until next month. That’s when I have budget allocated. So three weeks is plenty of time.” So we ended up putting it at the top of the product backlog and the team pulled it into Sprint number three and knocked it out. It was no problem.
So having just a little bit of friction in the process caused the right thing to happen. Hart had to think harder about the trade-off between focus and responsiveness.
Right, he could have gone the other way. If Ian had said “Yeah, we need it next week or I’m not upgrading,” we would have canceled the Sprint. That actually did happen on another Adobe team a few years later. They were building an early drawing app for the iPhone, which, if you remember, was very tiny in the early days; and in the middle of a Sprint, Apple announced this crazy new device called the iPad, and they recognized that’s a much better device to draw on, so they canceled that Sprint and re-planned around the new format.
So, let’s talk about the nature of the commitment a Scrum team is making when they plan a Sprint. As Peter mentioned in his first example, it’s a bi-directional commitment.
As developers, we’re committing to make our best effort to finish everything we pulled into the Sprint to the quality specified in our definition of Done so you can make larger plans and external commitments based on that.
As the Product Owner, I commit not to change the contents of the Sprint Backlog during the Sprint so you developers can focus on those items. But what if you can’t, for one reason or another, keep your commitment?
I think we need to acknowledge that almost every commitment we make carries some risk of the circumstances changing. If we think there’s a decent risk of something changing that might put the commitment at risk, we should probably agree ahead of time about what we’ll do if and when those conditions change.
We talk about a broader pattern for that in Episode 54, The Healthy Way to do Commitments and Accountability, so we’ll drop a link to that in the show notes.
Scrum builds that agreement into the process. With respect to the developers’ commitment, the Scrum Guide says, “Scope may be clarified and renegotiated with the Product Owner as more is learned.” The Scrum Guide doesn’t specify how that will happen, so most teams would need a more concrete agreement, but it does clarify that conditions might change that would put the commitment at risk, and a conversation with the Product Owner should follow. With respect to the Product Owner’s commitment, there’s the option to cancel the Sprint as we’ve already described.
We frequently get questions from leaders, sometimes from Product Owners, sometimes from managers, or executives, expressing some frustration that their teams never finish everything they pull into their Sprints. A recent VP put it, “Looking at the reports, we finish less than 60% of what we pull in to Sprints across these five teams. Our ‘say-do’ ratio is way off.”
There are at least three categories of what might be going on when teams regularly fail to deliver on what they committed to in Sprints:
- The work is highly complex and emergent, and changes and expands during the Sprint.
- The work has complexity that spans teams, making it nearly impossible to make a commitment and keep it.
- Everyone on the team works on their own thing in parallel. It’s like, “I’ll just pull this into the Sprint, not really because I expect to get it done this Sprint, but because I need something to work on.”
There are many reasons why those missed commitments might keep happening, and I think when we’re in that situation, we tend to either fix those reasons or make ourselves ok with it happening. Many teams do the latter, which starts to produce a culture where they don’t make and keep commitments in Sprints. It’s just not a big deal. Work just rolls from Sprint to Sprint.
But what if you want to fix it?
The first move is to simply treat a missed Sprint commitment as information and get curious about it. It’s telling you that things went differently than you expected.
Perhaps you discovered that the work was more complex than you expected. If that’s the nature of the work, then the nature of the commitment should be different. It’s not “We guarantee to get this fuzzy, unknowable thing all the way to Done this Sprint no matter what we learn,” it’s more like “We’re going to start building something to learn how to build it and what to build, and will collaborate with the Product Owner throughout the Sprint to update expectations as we learn.” Of course you’re going to want to slice those items small to reduce the effects of emergence. And you’ll want to front-load the complexity to learn earlier and faster.
Perhaps you discovered that the team has dependencies. That’s not necessarily a bad thing if those dependencies are predictable, where things aren’t going to change between the time the work was planned and when the teams finish it. Dependencies cause a problem when they span the complexity of the problem. Team A is working on their part, that causes new info to emerge, and that new info breaks Team B’s plan.
If that’s the case, the dependencies are not only preventing the two teams from keeping commitments, they’re slowing the work down overall because they have to wait for each other to respond to it. In that case, we really need to make the business case for how throughput would go up by restructuring the teams, and in the process, you’ll make it more likely for teams to make and keep commitments.
Or perhaps it’s that third cause; there’s something in how the team works together. Maybe the missed commitment reveals a hesitance to collaborate and a preference for working in parallel. So, explore why it might be worthwhile to collaborate, why it matters to get backlog items done faster, and consider running an experiment around collaboration like the 1-day Sprints we talked about in episode 86.
Notice that the fix wasn’t to push harder on the need for strong Sprint commitments. We hear from many leaders who, on the one hand, feel this impulse to say “We need to get our committed / delivered ratio up to 90%” or whatever, but at the same time, recognize that this would probably have unintended negative consequences, and I think the hesitance that comes from the second half of that is probably healthy.
I think there’s a basic human need to want to keep your commitments. Historically, it’s pretty hard to survive if you don’t. So, we shouldn’t assume people like missing commitments better than keeping them or that they just don’t care. Rather, let’s assume they’d prefer to keep their commitments, but something makes that feel too difficult or out of their control. And then let’s fix that root cause.
We’ve gone into lots of detail about how Scrum handles this tension, but for teams that aren’t using Scrum, you’ll still need to agree on how you’ll handle it. Asking people to make and keep commitments requires some acknowledgment that it’s not always possible to predict what will happen as we work on things, that there are many organizational factors that could make it much harder for people to make and keep commitments, and that sometimes we learn that the thing we’ve committed to work on is no longer the most important thing, or even worthwhile to work on at all.
Non-Scrum teams can use the patterns from Scrum as inspiration to figure out their own agreements on how to handle those big questions.
Thanks for tuning in to this week’s Humanizing Work Show. If you want to help spread ideas like these, the best thing you can do is subscribe to the show, leave a review and a comment, and of course share links on your social media accounts. You can send us your questions or episode ideas to firstname.lastname@example.org, 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.