What should Scrum Master do if Scrum Team hasn't reached an event goal after time-box expires?

Question

What should the Scrum Master do if the time-box of event has already expired, but the goal not reached yet?

This is the quote that made me think about this question:

So what do we do when the time-boxed sprint planning meeting is nearing the end and there is no sign of a sprint goal or sprint backlog? Do we just cut it short??? Or do we extend it for an hour? Or do we end the meeting and continue the next day?

This happens over and over, especially for new teams. So what do you do? I don’t know. But what do we do? Oh, um, well, usually I brutally cut the meeting short. End it. Let the sprint suffer. More specifically, I tell the team and product owner “so, this meeting ends in 10 minutes. We don’t have much of a sprint plan really. Should we make do with what we have, or should we schedule another 4-hour sprint planning meeting tomorrow from 8 am?”. You can guess what they will answer... :o)

I’ve tried letting the meeting drag on. That usually doesn’t accomplish anything, because people are tired. If they haven’t produced a decent sprint plan in 2 – 8 hours (or however long your time-box is), they probably won’t manage it given another hour. The next option is actually quite OK, to schedule a new meeting next day. Except that people usually are impatient and want to get going with the sprint, and not spend another bunch of hours planning.

So I cut it short. And yes, the sprint suffers. The upside, however, is that the team has learned a very valuable lesson, and the next sprint planning meeting will be much more efficient. In addition, people will be less resistant when you propose a meeting length that they previously would have thought was too long.

Scrum and XP from the Trenches. How we do Scrum. By Henrik Kniberg.

In reality, I think, there are only two possible solutions: To add some time to event or just interrupt it.

These are my ideas and what I did in my practice (my solutions may be wrong, that's why I asked this question):

• Daily Scrum. In really, I never had problems with time-box limit of Daily Scrum. But I have no objections to interrupt this event after 15 minutes.

• Sprint Planning. All that Henrik Kniberg wrote makes sense. But in my practice, I always just add some additional time. This problem happened very rare in my practice (but nevertheless has happened). It happened at the beginning of projects when Product Backlog is not yet well-refined. Much more often we spend much less time than Scrum Guide prescribes (which may be not good either, but that is another question).

• Sprint Review. This problem happens with me during Sprint Review more often than during Sprint Planning. Interrupt it and make new session on next day? No, thanks. It will be a painful to gather all stakeholders on unusual day. Don't make new session at all? It may harm next Sprint. So, I always added some additional time, if time-box is not enough. If it is not right decision, please correct me.

• Sprint Retrospective. As in a case of Daily Scrum, I have no objections to interrupting this event if time-box is expired.

About Product Backlog refinement: In reality, I never calculated exactly what percentage of capacity it took. But I think there is nothing terrible about it being more than 10 percent, especially toward the beginning of the project.

Answer 1

The purpose of the time boxing in Scrum is to act as an alarm for the Scrum Team. When the time boxes are regularly being exceeded then there is a problem that needs to be addressed.

As a Scrum Master this is what I would do in this situation.

With the Daily Scrum I would not interrupt the meeting at 15 minutes. Instead, I would look to interrupt individual team members who are talking for too long on topics that are outside the scope of the Daily Scrum. A rule I generally use is that if a technical conversation in the Daily Scrum goes beyond 40-60 seconds I would suggest it is taken offline and outside of the Daily Scrum.

With Sprint planning a long meeting is a strong indication that not enough backlog refinement is being done. Scrum suggests 10 percent of the time in a sprint is spent preparing for the next sprint, but this is just a suggestion. For some teams it will be less, other teams it will be more. Really the time spent on backlog refinement should increase until there is no longer any benefit being gained by increasing if further.

Another important point about Sprint Planning Meetings is that it is not necessary to plan everything in the sprint in exact detail. The Scrum Team should decide on what is going in the sprint and then spend a time-boxed amount of time discussing how they will deliver this work. The most important thing is to have enough understanding after the planning meeting for the team to start the sprint. It is not necessary to plan in detail the entire sprint because there is plenty of opportunity for the team to meet again to discuss this detail during the sprint itself.

So for the Scrum Master to interrupt the Sprint Planning is perfectly natural. I often say to the team: "We have enough planning done to get started. Lets start the sprint and meet up again after a few days if we need to to discuss what has not been covered in this meeting".

The Sprint Review is all about getting feedback from the stakeholders. Feedback from the Product Owner should have been gotten during the sprint itself, so by the Sprint Review the Product Owner should have few if any questions to ask. Feedback from the stakeholders by definition is open-ended. Therefore it is important the Scrum Master and Product Owner educate the stakeholders that they only have a finite amount of time to provide feedback during the Sprint Review meeting. That again is a situation where the Scrum Master could step in and interrupt. Perhaps suggesting that the Product Owner and stakeholders meet up again later if there is any further discussion to be had on requirements.

Sprint Retrospectives can easily exceed the time box. The Scrum Master needs to use the structure of the meeting to avoid this. For example, I will often run a Sprint Retrospective like this:

First 10 minutes - team members write their feedback on post-it notes. Next 15 minutes - the Scrum Master reads through the notes with the team and attempts to identify one (or possibly two) areas in which to focus on. Final 30 minutes - discuss a possible improvement and agree to bring it in to the next sprint. If the improvement is highly complex I might suggest that it is put on the backlog as a task. That can then get sized and formally brought in to a sprint when it is appropriate. It would not be necessary to solve all the problems completely. Just to establish what was going to be worked on.

Answer 2

"What Scrum-Master should do if this problem (time-box is expired, but goal not reached yet) already happened?"

Make the team feel the pain so they become aware that there really is a problem. Awareness is always the first step. People have thicker skin than you'd like or know. But...you know your team best, so you judge which action will create the pain and most quickly bring about the desire for the team to resolve that pain.

Do they respond the most (feel the pain) when you schedule something the next day? Then don't shy away; schedule a follow-up the next day and keep them there until the job is done or until they are on the brink of becoming un-productive or demoraled. Afterwards ask them if they enjoyed it and what ideas they have to avoid the situation in the future. You don't need to wait for a retrospective to discuss changes. You're empowering the team to solve their problem while it is still fresh in their minds. Then hold them to their proposed solutions. Rinse & repeat as necessary.

Lastly, when you follow the Scrum framework for the sake of following Scrum, you cease to be Agile.