Following the discussions both elsewhere and on this blog about sprint duration, the questions poses itself - what is the preferred sprint length? So I ran a poll.
And the winner is... 2 weeks.
According to this very scientific survey (1 week on my blog, 228 Visitors, 50 votes), the most popular sprint duration is 2 weeks, followed by (early leader) 3 weeks, which lost by one vote.
The final results are:
|1 week||2 (4%)|
|2 week||18 (36%)|
|3 week||17 (34%)|
|4 week||5 (10%)|
|1 month||5 (10%)|
|longer, but fixed||5 (10%)|
How long should the sprint be? There are many right answers, some of which argued for longer sprints:
- The longest time you can shield your team from changes in work
- bigger/harder stories imply longer sprints
But most argued for shorter sprints:
- It should be short compared to the length of the project
- Quicker response to changes/new information
- More and earlier data points for measuring velocity
- Achieving closure - there is a feeling of success associated with a successful sprint - the more often the better
- Agility (and ROI) - the shorter sprint sprint, the quicker you can get functionality to the customer or user
- Feedback - the sprint end is a chance to learn from the customer and from yourselves - the more often the better
- Reliability of Commitment - the deadlines are nearer, the committments fresher in your memory
Mike Cohn pointed out:
3-week sprints have become very popular over the last 12-18 months. Before then most teams considered them odd ;) Seriously, it's a recent change for most teamsAnd the closing word:
The preferred sprint duration is the one that works best for your team :)I'll second that!
Thanks to Dmitry, Ben, Ash, Ilja, Paul, Kiran, Paddy, and Brett for their comments, as well as to everyone who voted!