Dominique Stender Good software is only the beginning

The ideal sprint length

When I started with Scrum, I was very cautious. I thought that with all these changes and the new mindset that had to settle, the transition would be easier if I started with longer sprints. Back then I started with three week sprints. Now, this length is perfectly well within the commonly agreed upon boundaries. Certainly the three week sprints didn't do any harm but since then I shifted to frist ten day sprints, then one week sprints and I have had much better results with shorter sprints.

I've isolated a couple of reasons why I believe shorter sprints result in higher quality and higher velocity that I want to share:

First, we had a release cycle of roughly two to three months. Having three week sprints simply gives you very little "wiggle room". There too few sprints for any mayor course correction! Mind you, no change permitted within a sprint! With only three to four sprints in a release there is hardly any chance to start with a rough idea at first and custom-fit it during the release by refactoring those parts that did not work. With shorter sprints you simply have more reviews and hence, more feedback loops.

Second, specifying and planning enough work for a three week sprint properly is hard. There's an unnerving similarity to a requirement specification that is carved in stone back from the not-so-agile days. See my first point on this as well. With shorter sprints your planing is more flexible. You can navigate better with less "requirement visibility" in short sprints.

Third, with a team that was technically well experienced but new to Scrum the planning meeting seemed to take forever. Routinely we would sit in the conference room for three hours or more only to leave the planning session mentally exhausted. As a result the productivity for the rest of the day suffered a lot. The same is true for the review meeting by the way. I have yet to meet a developer who loves meetings. Short sprints help to keep them short.

Fourth, I experienced a small waterfall process happening within each sprint. For two weeks or so the team would *cough* "finish" *cough* all tasks and then spend the third week testing, bugfixing and writing documentation. Last time I checked that is not the idea behind Scrum. With short sprints I could prevent the in-sprint waterfall. There simply is more pressure (the good kind) to get a task DONE the first time and not require a distinct testing phase in each sprint.

Fifth, you and your team will get more practice to do good and efficient planning, rewiew and retrospective meetings when the sprints are shorter - you simply have more of them. This extends to quality in general - with more feedback from the Product Owner and stake holders, the team will get a much clearer view on where additional improvements are required. Because of this I experienced an increase in quality very quickly after shortening the sprint length.

The sixth reason for shorter sprints is a better break-up of tasks. Since the goal of a sprint is potentially shippable software increments larger tasks have to be broken up into much smaller chunks in oder to have "something" shippable after a short sprint. In my experience, this has two advantages: A better and more in-depth discussion about requirements in the early phases of the release on one hand and better estimations on the other. It's the age old divide and conquer paradigm: A small chunk of of work is better understood and hence implemented with higher quality and closer to the requirements with a better initial estimation than a larger one. Note that of course nothing stops you from doing a good break-up even when you have long sprints. But in short sprints, you're forced to do it.

Six compelling reasons why shorter sprints might be better than longer ones. Better? yes. Easier? Probably not, at least not at first. Currently one week sprints are the limit for us. We need to increase our amount of automation (Unit testing, frontent testing, continuous integration) in the project in order to reduce the sprint size even further.

That aside, I'm not sure whether or not a sprint length of let's say three days makes sense. It will break the weekly rythm and from what I see, people like a steady rythm. Imagine having planning meetings on Monday for sprint one, then on Thursday for sprint 2, Tuesday for sprint 3, Friday for sprint four and so on. Usually the organization around your team will breathe in a weekly rythm - board meetings, cross project knowledge shares and all other meetings tend to be in a weekly, bi-weekly or monthly pattern. With your team having a sprint length that is not a multiple of a week, I see them having to skip those other meetings quite often. To make it short: I don't see it work.

The ideal sprint length for you depends on many things, including the complexity of your software and non-technical requirements that you'd usually find in your Definition Of Done. Maybe two weeks is a really short timeframe in your situation. Maybe a week seems awefully long. I'd suggest to start with a sprint length that is challenging, but not scary. That way I was too cautious to start with three week sprints. Once things run ok, or if you keep encountering one or several of the situations I described above, ask the team whether or not they want to shorten the sprint by one week. Look at the results for maybe tree sprints and see if it worked.

You can keep doing this, shortening and lengthening the sprints by one week increments until you find your own sweet spot.

Have you found your sweet spot already? How long is it? Did you encounter other reasons why a shorter sprint length seems to be better than longer ones or maybe a reason against short sprints? Let me and all other readers know! Leave your opinion in the comments!

Related Posts:

• Pen & paper Scrum – 10 days edition
• Scrum with pen & paper
• Ken Schwaber’s “Confusion about Scrum”
• Attempting Scrum in a SDLC environment, pt. 2
• Attempting Scrum in a SDLC environment, pt. 1