It's always good to have a Plan B. And all Scrum teams do--it's called an abnormal termination.

An abnormal termination is essentially blowing up the sprint and starting a new sprint instead. An abnormal termination is most frequently the result of a dramatic shift in business priorities--something previously considered important is no longer important, or something even more important is discovered.

But an abnormal termination can often be called if the team gets partway into a sprint and discovers that the work is going to take much longer than they'd anticipated in sprint planning. Sometimes a few days of experience with a new technology or in an old part of the code reveals that implementing something will take a lot more effort than previously thought--so much more, in fact, that the product owner may not want the functionality at its new cost.

A question I've skirted around in writing the preceding is: Who decides if an abnormal termination should be invoked?

To me the answer is very clear, but there is a lot of debate about this among Scrum trainers. My opinion is that the product owner makes the call. However, many people say it should be the ScrumMaster. Let's look very practically at why it cannot be the ScrumMaster who makes the decision.

Suppose a ScrumMaster and product owner are at odds over abnormally terminating, with the ScrumMaster in favor of it. If we decide that ScrumMasters are the ones empowered to make the decision, this sprint will be abnormally terminated. The first thing a team does after any abnormal termination is plan a new sprint.

The planning meeting for the new sprint will begin--as all sprint planning meetings do--by asking the product owner what should be worked on. And the product owner will reply, "Exactly what you were working on 10 minutes ago, before the ScrumMaster called for an abnormal termination."

And there's the problem: A Scrum team works on what the product owner wants. If a Scrum rule gives the ScrumMaster the right to abnormally terminate, a product owner who disagrees with that decision can nullify the abnormal termination by having the team work in the "new" sprint on exactly what they were working on in the abnormally terminated sprint.

So giving authority over the decision to abnormally terminate to ScrumMasters doesn't work. I completely understand the appeal. It makes absolute sense until thinking through the implications, and then we realize it can't work. The decision to abnormally terminate must be given to product owners.

In wrapping up, though, I want to point out that authority over this decision is a bit theoretical. In practice, I've never seen a situation where a product owner, ScrumMaster, and team disagreed over abnormally terminating. Sure, it might take some argument and discussion to create consensus, but I've never seen a situation where the product owner, ScrumMaster, and team cannot come to agreement and need a dispute resolved by an authoritarian decision-maker.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

You’re right, of course, in pointing out that this post didn’t go through all the options that should be considered before abnormally terminating. Abnormal terminations are rare—and should be. You’re right that is is absolutely the last option. As you say, there are huge consequences to abnormally terminating a sprint (team loses trust in the product owner being able to prioritize, effort is wasted, effort needs to go into re-planning and on and on). All I wanted to do with this post was argue that it has to be the product owner who ultimately makes the call. You are also right that something as important as this should never be decided upon lightly or without consulting others involved. A lot of people do think the ScrumMaster gets to ultimately make the call. But whenever I’ve argued my product owner position with someone who thinks it’s the ScrumMaster we have always agreed that the decision should be made jointly. I think I said in the original post that I’ve never seen a product owner and ScrumMaster disagree in a real situation. So, the argument is a little unnecessary. I wrote it, though, to clarify that if there is a dispute, it has to be decided by the product owner (after using every facilitation skill possessed by the product owner and ScrumMaster to try to achieve consensus). Thanks for your comments.

Posted by mikewcohn on 2014-05-20 13:54:29

I can't imagine a working team where the Scrum Master in power to abnormally terminate a sprint would be making a mistake. What kind of a Scrum Master would he/she really be, then? It *shouldn't* be the Scrum Master's decision anyhow, but I guess he/she should understand the consequences and not make this decision by himself/herself.

I would also actually disagree that the decision should fall solely on the Product Owner. Of course, he or she could (maybe even should) be the incentive to terminate a sprint, but when the priorities change or something more important happens, there are many other options before you make the drastic decision to abnormally terminate a sprint. I didn't find other options in your article. You can always replan a sprint, when you remove some issues and add new ones. If it's a critical bug, that needs to be fixed right away, at my company we use the procedure we like to call a Silver Bullet. It means the team stops working on the issues at hand and focus on finding the solution. Every sprint we plan some time in our capacity for potential Silver Bullets.

An abnormal temination should be the absolute last option you try and that is why a whole team (PO, SM, the development team, stakeholders, sometimes even the company's CTO) should be involved in trying to solve this situation.

I'm sure you didn't mean that one could abnormally terminate a sprint without any consequences. Your article just lacked other options and I wanted to clarify that.

Posted by Ola Przydryga on 2014-05-20 04:42:38

It will definitely ease your work of handling a bigproject. As a project manager I use scrum in my projects. One of my friendsreferred me to use the Guide to Scrum Body of Knowledge by http://www.scrumstudy.com.I like the concepts of sprints, daily standup meetings, etc. the SBOK Helped mealot in Understanding how AgileProject Management works.

Posted by Olivia Jennifer on 2014-05-01 04:23:40

I completely agree with this. In Scrum, teams select the amount of work they can do. And product owners cannot unilaterally introduce scope increases mid-sprint.

Posted by mikewcohn on 2014-03-19 20:34:52

The Product Owner is responsible for the Priority. The Dev Team for the sprint scope. If for any reason the PO feels like the scope is not what he needs, he is free to reprioritise before and during the planning meeting. If the Sprint has been started and the team can not accommodate the changes he needs, I want the PO to explicitly abort the Sprint. Just today I've had a Product Manager nag the team about taking something else on that wasn't planned during the planning meeting, and when asked what he would like to replace with it (only 1 Story really comparable in scope) he said he needed it all and whether the DEV team couldn't work weekends to make it. The Planning Meeting was yesterday, mind you. So no, the DEV Team can not decide what the priorities are. But the PO can not decide to increase the scope against their will (and better judgement).

Posted by bertholdbarth on 2014-03-19 15:59:15

I completely agree that teams need to be invested in their product. They need to want it to be successful and they need to hold product owners accountable to do the thinking to make that happen. However, I get concerned about a statement that the team “demand a PO abort the sprint.” Anything like that has an implied or stated “or else…” to it and I want to know what the team is threatening. A Scrum team does not have the right to overrule what the product owner wants—that would make them the product owner.

Also, rather than halfheartedly accepting scope changes, I welcome a team actually demanding a PO abort the sprint. I very much prefer teams that explicitly decide to not to deliver things in favour of other things to teams that aim to please and in the end deliver nothing of substance.

Posted by bertholdbarth on 2014-03-19 11:14:56

The problem is - this is the real world we live in, and Scrum can't live in a crystal ball, ignoring the realities. Humans are not perfect and product owners are usually a manager from an external company and often another country.

Posted by Tudor on 2014-03-10 04:51:43

Hi Andy—

I read a great article last week on Human Resources policies at Netflix. (I’ll dig up the reference but the magazine is at home and I’m not.) What I really loved was their former HR VP saying how the company would only hire “fully formed adults” and that when you hired people like that, many problems went away. That’s great! If we hire true adults—people who take responsibility for their work—we don’t have issues like how do we get people to work hard. All this really has me wondering how we get people to behave as they should. Screw all this agile stuff—the improvements brought about by agile are *trivial* compared to what organizations could see if they got everyone to behave responsibly and maturely. Thanks for giving me something to think about. I want to find ways to help more organizations get fully there. I’ve seen it at too few.

Posted by mikewcohn on 2014-03-07 01:29:08

Hi Parag—

You offer good advice. If something is very uncertain, teams really have two choices: (a) dive into it in the current sprint, leaving enough room in the sprint to handle a reasonable but bad case assumption (“This gets hard but not worst case”); or (b) run a “spike” in the current sprint to reduce that uncertainty and then go for it in the second sprint. The second approach can smooth out work across sprints as long as it’s not necessary to try to get the feature ASAP. And good point of bringing up trust—that is always key. Thanks.

Posted by mikewcohn on 2014-03-07 01:24:37

Yes, and unfortunately this underlying culture of distrust, assumption that people are just looking for an occasion to slack away and avoid work, is something I encounter quite frequently when teaching. People ask questions like: how we get people to work, how we make sure they really work as hard as they can and the like are a signal trust is missing or at least the level of trust is very low. This is quite frequently mixed with treating the PO as someone outside the team, someone who pushes the team to do stuff team doesn't really want to do. You're right - I find it more rewarding to help teams that don't have these underlying issues be even better than the ones who do cope with their problems.

Posted by Andy Brandt on 2014-03-05 09:02:32

The urge to terminate seems more apparent when the team dwells into quite a lot of un-knowns at the sprint planning session. One way to slightly mitigate this is to have some time spent by team members in previous sprint to go over the next sprint stories. This may still not be enough but might help.This re-alignment of scope will always happen and teams should win the trust of the product owner to be able to convince him and get his buy in as he would as you said should be the final decision maker and the messenger to business. This is the beauy of Agile where unlike other methodologies, the intention is not to play a blame game but cohesively work towards a solution.

Posted by Parag on 2014-03-05 06:42:07

HI Andy—You raise some points here. I want to comment specifically on two:

Yes, while Scrum can help the totally dysfunctional teams of the world start to improve (by pointing out their problems), Scrum really does assume trust and good intent from everyone. Personally, I’m much more interested in helping good teams who want to become great get there rather than working with the truly messed up teams. I read an article last weekend about HR policies at Netflix and one of the comments was they hire only “fully formed adults.” Starting with that assumption made a lot of other HR policies easy for them such as their policy of unlimited holiday/vacation time. I’d like to assume the same of Scrum teams. When the assumption doesn’t hold, we can still address the problem but I don’t want to optimize Scrum for messed up teams in favor of good ones who want to be great. Second, you are absolutely right that abnormal terminations are not a weapon to be wielded by the product owner. Until you mentioned that, I’d forgotten about occasionally seeing product owners who will say, “Well, then I’ll just abnormally terminate.” Great point. Thanks.

Posted by mikewcohn on 2014-03-05 01:12:56

One more point worth considering here is that Scrum is laid on an assumed foundation of mutual trust, goodwill and communication in the Scrum Team (with SM as its custodian). In that sense all the "rules" of Scrum are suggestions for considerate, mature persons and that includes the PO. Abnormal termination is not a tool for POs to change course mid-sprint whenever they so fancy. It is also not something to threaten the team with if they object to "adjusting the sprint scope" mid-sprint.

Posted by Andy Brandt on 2014-03-04 14:35:04

When I explain a need for a sprint I rather focus on another aspect of it, which is that it requires a fully completed increment to be periodically reviewed by stakeholders (and the PO and the team of course). This enables empiricism by forcing a periodic inspection of the state of the product and the endeavor (project) that produced it allowing stakeholders to adapt through feedback they share with the team. In other words, thanks to sprint there is a constant "heartbeat" of inspecting & adapting guiding the development in the right direction. One could do it probably too without formally having a sprint, but there would be more potential then for inspection to be somehow incomplete (as some stuff will not be yet "done" etc.).

Posted by Andy Brandt on 2014-03-04 14:31:10

Hi Wiktor-

You raise an interesting point about the PO. But, I don’t think the PO exists only because of communication problems or to solve a dysfunctionality. I think that a product owner serves a very important role and will exist in even the healthiest of organizations. I agree that in healthy organizations everyone takes on some of the responsibilities that would normally reside with a product owner or ScrumMaster. But rather than eliminating the need for a product owner, that should free the product owner up for more of the duties that were not taken on by other team members. As for not needing sprints, I strongly believe that iterations (sprints) are beneficial for nearly all teams/individuals. I can’t find research on this that I saved in a pile of academic papers while writing Succeeding with Agile but I know I read something along the lines of people performing best when they have short-term but realistic deadlines. Beyond just research though, I totally believe that. In the mid-90s when I was starting with Scrum we also experimented with teams that were doing something similar but just trying to go fast without the iterations. It didn’t work nearly as well. That’s just anecdotal, of course, but it totally fits everything I’ve experienced. There’s a benefit to getting together at the start of a time period, saying what you’ll do by the end of that time period, and then seeing how you’ve done. So much of that seems to fit the rest of how we work—e.g., a sales organization could be told “just sell as much as you can as fast as you can.” Yet I bet sales organizations do better with periodic review points (“sprints”), usually monthly or quarterly goals.

Posted by mikewcohn on 2014-03-03 14:03:00

Lets look at it from different perspective. If we just could assume that PO role is just a little dissfunction or more solution for a bussines-IT communication problem. Without this dissfunction the decision about sprint termination would be just up to the team.

Don't understand me wrong I'm not saying that Scrum sucks and you don't need product owner, I just want to say that I've also seen mature agile teams where everyone played a role of some kind PO and/or SM.

Looking at it a little bit closer... Let assume that we don't have Sprints at all and we are delivering small batches of software in an incremental and continuous way. Than there is no problem in sprint termination.

Again don't understand me wrong - in many cases you need Sprint. The reason why we need sprint is to "freeze" some part of scope and improve short time planning which suck in many orgs. It also helps in learning how to build products incrementally. But I've also seen mature agile team wchich don't use Scrum at all but, or I should say Agile organisations not just a teams, which use for example Continuous Delivery and BDD. Many of this teams starts with Scrum and than evolves intoor Agile and Continuos Development orgs. I just want to say tha Scrum is a great tool for making organisations Agile, but implementing Scrum by itself shouldn't be a goal for the organisation. So focusing on the problem: who should decide about sprint termination or another scrum related issues is not the point. If there is problem like this visible it probably means that this is probably a symptome of another problems like communication, technical debt, decision making, transparency etc...

Posted by Wiktor Żołnowski on 2014-02-28 12:31:21

Great story, Joe. Abnormal terminations should never be called without plenty of consideration. Thanks.

Posted by mikewcohn on 2014-02-27 18:27:44

Totally agree Mike. It should be the PO's call. While I Nokia, we viewed the abnormal termination of a sprint to be very serious. The reason was it could affect other teams ability to deliver. Often there were dependencies involved, especially at such a large scale. So, while the PO could "suggest" the termination, it had to be coordinated and approved at the program level, so impact could be assessed. I only saw it happen once, and as a result, it involved a product replanning effort.

Posted by Joe Vallone on 2014-02-27 18:13:46

Hi Greg—I agree. Scrum Trainers will debate very picky things. This would didn’t generate a lot of discussion, fortunately.

Posted by mikewcohn on 2014-02-26 10:50:01

Well if you have "never seen a situation where a product owner, ScrumMaster, and team disagreed over abnormally terminating",it's a bit of a shame that there is "a lot of debate about [Who decides if an abnormal termination should be invoked] among Scrum trainers". I guess you guys should better debate about other stuffs then :)

Posted by Greg HB on 2014-02-26 05:17:08

Thanks, Tara.

It would be interesting sometime to see a pie chart of the actual causes of problems on projects. The biggest wedge in that chart would have to be labeled “Communication Issues.” It’s rarely some deep technical issue that derails a project or sets it back. It’s almost always a communication issue. And you’re right about having good communication across all paths. As a consultant, whenever I see a project with any rule along the lines of “All communication to person x must go through person y,” I know the project will be in trouble. Thanks for your comment.

Posted by mikewcohn on 2014-02-25 22:34:01

Hi Adam—

Great points.

I think it would be easy to conclude the ScrumMaster makes the call if one doesn’t think about it very hard. For example, if I ran up to you and yelled, “No time to think! Who can call for an abnormal termination?!!” I can completely see a majority of people saying the ScrumMaster. I often equate the ScrumMaster to a “process owner” in balance with having a product owner. So I get that. But if one really thinks about it, I don’t see how anyone can stay with that answer. It’s kind of my point in the post, it’s not some deep philosophical issue. It’s really just a matter of practicality—if anyone else gets to call the abnormal termination, the product owner just says, “OK, next sprint let’s do…exactly what we *were* doing!” So, yeah, it just doesn’t work if it’s anyone else. I’m completely with you that a good ScrumMaster should be trying to put themselves out of a job. But, wow, wow, wow—that issue just came up recently with a group of Certified Scrum Trainers and caused a huge set of arguments to surface. There were some who were quite vocal that a ScrumMaster is never anything but an absolute 100% full-time job and that a good ScrumMaster won’t even take on a coding, testing, design, etc. task but will instead sit patiently waiting for an impediment to arrive. I can’t imagine someone with that perspective being ok with a ScrumMaster who has put himself out of a job (or even close to it). I use the metaphor of ScrumMaster as coach and usually mention that basketball is my favorite sport. I then point out that while it’s possible for a team to be so good they barely need a coach, it’s going to be pretty rare. I’ll talk about how ScrumMaster can be combined with another role on the team once the team achieves a certain level of proficiency. But I point out even then it’s hard to reach the pinnacle of their performance with such a “player-coach.” I point out that the last time this happened in basketball (NBA) the player-coach was Bill Russell in 1969. I think it’s an interesting question of whether a team can ever get so good they can go entirely without their ScrumMaster—that is, can the ScrumMaster entirely work himself out of a job. Ken (of Scrum.org) and I discussed that many years ago. At the time he was “No” but it wasn’t an absolute. I got the sense he thought it possible although pretty much impractical. I’m personally much more open to it. I’ve spoken to a few sports coaches who have said all the coaching happens in practice. Well, sprints seem like the game so maybe it can happen. Thanks for the thought-provoking comment.

Posted by mikewcohn on 2014-02-25 22:16:38

Great post Mike! I love the example, 'What you were just working on 10 minutes ago!'. How does the role of scrum master get so misaligned?

A functional team would have the Devs communicating with the SM that 'new information' was discovered during the daily, which in an ideal world, the PO would be at that daily to hear this info and btwn the SM and PO (and hopefully team too) the discussion would be had and the PO would call it, if they saw it appropriate, or change the next sprint depending on the priority of what was discovered. Seems so obvious when you have a team that is working together, communicating and all moving towards the same shared goal.

Posted by Tara Snow on 2014-02-25 12:53:35

This is another spot where I am surprised that there is debate. I will admit to not having been in a CSM class as of yet. I do have a PSM 1 attained through self-study and experience. For the PSM Scrum.org's Scrum Guide is the definitive authority on Scrum. Right in the guide, plain as day, it states "Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master." Normally this is where I would have some kind of "the devil is in the details" disclaimer, but I see none available here. Considering that the Development Team is there to provide value for the Product Owner, even without the aforementioned statement from the Scrum Guide it makes sense that the PO is in charge of deciding whether or not to cancel a sprint.

IMHO the Scrum Master really shouldn't have much to say about the actual product and development itself. The SM is there to maintain the process, "protect" the team, and coach the PO. Much like an Agile coach the SM should be trying to put themselves out of a job. For a high-performing team the SM should be working to create a "Scrum-And" environment where the team can be even more successful. In the long run, I also feel a SM should be willing to move to "Scrum-but" if that best suits the team, however that discussion is for another time and place.