An important consideration for every Scrum team is how long its sprints should be. Choose a length that’s too long, and it will be hard to keep change out of the sprint. Choose a length that’s too short, and a team may struggle with completing significant work within the sprint or weaken their definition of done to do so.
But who is it that gets to select a team’s sprint length? 
Of course, the answer is the whole team – that collective of ScrumMaster plus product owner plus team members such as programmers, testers, designers, DBAs, analysts and so on.
But what if that broad set of individuals cannot agree? Do they argue endlessly, perhaps sticking with their waterfall or ad hoc process until consensus finally emerges?
No. The ScrumMaster is ultimately the one who gets to choose a team’s sprint length.
A good ScrumMaster will do everything possible to arrive at a consensus. But, when the ScrumMaster exhausts his or her collaborative, facilitative skills without arriving at a consensus, the good ScrumMaster makes the decision.
This should not happen often. I hope most ScrumMasters never need to say, “I’ve listened to everyone, but here’s what we’re doing.” But since the ScrumMaster can be considered a team’s process owner, the ultimate decision does belong to the ScrumMaster.
Let’s consider one example from my past.
In this case, I was consulting to a team doing four-week sprints. They were struggling to pull the right amount of work into their sprints. For the six months before I’d met them, team members were consistently dropping about a third of the work each sprint.
They were a good team doing high-quality work. They simply didn’t know how much of it they could do in four weeks. Their optimism was getting the better of them, and they were consistently overcommitting.
I asked the team to think about how they’d like to solve the problem and tell me their suggestions the next day. I was thrilled the next day when they announced that they should clearly change the length of their sprints. “Yes,” I told them, “Definitely.”
They were relieved that I agreed with them and said so: “Wow! We didn’t think you’d let us go to six-week sprints!”
I had to inform them that while I agreed with changing sprint length, the better solution would be to go to shorter rather than longer sprints.
We ended with me—as a consulting ScrumMaster—setting a two-week length.
Why did I do this?
The team was already pulling too much work into a four-week sprint. They were, in fact, probably pulling six weeks of work into each four-week sprint. But, if they had gone to a six-week sprint, they probably would have pulled eight or nine weeks of work into those!
This team needed more chances to learn how much work fit into a sprint (of any length). As their ScrumMaster—especially coming to the team as a consultant—I could see that more easily than they could.
I want to end by repeating my caution that this is not something that should happen very often. I can count on one hand the number of times when I’ve flat-out chosen a length for the team after failing to gain consensus.
I’ll stand by the value of having done so in each case. But I only did so after significant effort to gain consensus. Overriding team members on something as important as sprint length should be done with great caution. But, it’s a process issue and, therefore, in the domain of the ScrumMaster.
What about you? Were there times when your team couldn’t agree on a sprint length? How did you resolve it?
