How long to Sprint?

As we were preparing to use Scrum, the customer asked, How long should a Sprint last? What is the right length for a Sprint? Should it always be the same, or can we vary the tempo?

There are general considerations, but these will be influenced by the specific situation.

Here in Switzerland, the public transportation runs on a beat. The intercity train from Zürich to Bern leaves every half hour. There’s a train on the hour and at 32 minutes past the hour, every hour, and they arrive 57 minutes later – dependable and predictable. This is a good reputation for software teams to strive for.

The neighborhood bus that takes me home applies almost the same deal: 17, 37 and 57 minutes past the hour during rush hour. But during the day, the bus suffers from what’s known as a Taktbruch – breaking the rhythm. During the day, it leaves at 17 and 47, and on the weekend it’s completely different. So I have to remember when which frequency applies, which makes me (and everyone else) much less likely to use it.

So, lesson number one about Sprint duration: it’s OK to experiment at beginning, but then you should set a duration and then stay with it. That makes it easier for everybody.

Based on the bus & train example, you might think shorter is better — If that bus comes every 5 minutes, that’s more convenient for the customer — but a passenger has no work to prepare for the bus’s arrival, except when s/he actually plans to take that bus.

Short sprints do have a number of advantages:

• Intense customer contact
• Frequent Examination of Project Situation
• Quicker Feedback Cycles
• Good for Building Trust with Customer

But short sprints are not without their disadvantages:

• Harder to tackle big problems
• More Meetings and Preparation
• Developer Acceptance

In my experience, one of the hardest parts of adopting Scrum has been convincing developers that they can deliver incrementally. This is made more difficult by limiting the time available for Sprint. (Having said that, once the developers are convinced it is worthwhile to release incrementally, then convincing them that they can actually do it becomes easier.)

More meetings can be an issue. Sprints have a regular meeting cycle: Preparation (Scrum Master and Project Owner), Estimation (Team), Sprint Planing I & II (all), Sprint Retrospective (team). This predictability is good, every thing can be planned months in advance, but it occupies a lot space in your calendar. There may also fixed costs associated meetings, e.g. travel time, so the time spent in meetings may not shrink linearly with duration of the Sprint.

In our case, we had seven weeks to clean up the software and get out a release by Christmas. We started with a two week sprint. I had proposed a one month sprint, but the customer wanted to have a chance to influence the process. So we did 2 – 2 – 3. The second and third sprints were release Sprints. Functionality developed in the previous sprint was shipped (tested and accepted by the customer) and deployed on the live server. The second release was a “major release”, with database changes, so teh customer wanted to do more regression testing, but since three weeks was what we had available, it worked out perfectly.

We noticed quickly that Sprints on a two week cycle was a lot of work for everybody involved, especially the product owner (who previously, as a mere customer, had relatively little to do). But the P-O was wary of not being able to influence the development for a month at a time, so we decided on a three week sprint interval.

This proved to be a good compromise, somewhat unconventional, but even after 22 sprints (and yes, Virginia, once in while, we did make changes to the plan to accommodate issues we couldn’t control), no-one is talking about changing the beat.