The right Sprint Length

In order to keep the blog short here is the answer:

     Let the Development Team decide

If you are curious why this is the answer then keep on reading.

Again and again, I hear from outsiders that we should extend our Sprint length. Usually, I like to work with two weeks. When I ask for a reason, the answer is typically the following: 'With all the meetings you don't have time to do real work, so I think you should add another week or maybe even two!'.

Interesting statement, but completely wrong and obviously from someone who does not understand Scrum. 

Here is Why:

1)  Apart from the 15 min Daily Scrum all meeting durations are proportional to the Sprint length. The Product Backlog grooming which is paramount to an executable Product Backlog and often neglected in literature is about 5% of the Sprint length in average by my experience . 
Here a chart showing how the meeting time per day actually slightly increases when the Sprint is longer

2)  All of the above meetings are real work and important. They are the empirical process controls you need when you work in complex environments and domains. Especially the Daily Scrum is the catalyst for an effective and hence productive working day. The Daily Scrum is not disruptive it creates focus and team spirit. I just read the slides of a recent talk of Tobias Mayer. He stresses that Scrum is essentially five things.

• self-organization
• collaboration
• focus
• alignment
• rhythm

Each of these points is addressed by one or even a couple of those meetings. 

3)  The rhythm is to be discovered by the team. In my experience two weeks is a great fit for most environments but if the team cannot find it's own rhythm and cadence within a given Sprint length, then let the team decide. Often they adjust their defined working rules, and sometimes they decide a different Sprint length is what they need. If so, let them choose whether they want to go shorter or longer. The rhythm is a function of the domain, the planning horizon, team configuration, dependencies, other Scrum Teams, and more. It cannot be decided by an outsider.

4)  Finally, the underlying problem is, that people with that recommendation are usually bottlenecks themselves. It is a latency issue by those very individuals. When problems do pop up it takes too long for them to turn around. Since a loss of a couple of hours or even days is more visible or shall we say dramatic in a two weeks Sprint then a four weeks Sprint. Those 'well' intended recommendations try to mask the problem and thereby slowly turn the project into a ScrumBut.