Finding the right iteration (sprint) length
From the blogs and articles I’ve read of different companies have implemented Scrum, it seems that the most popular iteration lengths are either 2 or 4 weeks. When we first adopted Scrum over a year ago we decided to go with a 2 week iteration. I wasn’t Scrum Master at this point so I can’t say for sure why we decided on this length, but there does seem to be a lot of support advocating this as the best choice when beginning with Scrum.
Things to consider
- How quick can we react to change?
Once an iteration has started, there should be no unforeseen changes to the team’s workload. In theory, if new work comes in then either it will be high enough priority to warrant terminating the current sprint and starting again (NOT something you want to happen on a regular basis, since it means wasted effort on the planning and starting of a sprint) or it waits until the planning meeting for the next sprint. Would the business be happiest having to wait 2 or 3 or 4 weeks for the scrum team to start working on a new piece of work? - How often should we feed back to the customer?
At the end of every iteration the customer has the opportunity to review the work that has been completed, allowing them to know if changes are needed early on in the project. The longer the iteration length, the fewer opportunities the customer has review the project. - How well does the team know Scrum?
If your team is relatively new to Scrum it may be beneficial to start with a shorter iteration length, since this means the team gets a feel for it quicker and has the opportunity to discuss and improve the Scrum process more often in their retrospectives. - How big are your user stories?
A larger iteration length means that a team can tackle larger pieces of work in it.
With our two week iterations, we started to find that some of our user stories got chopped up into “dev stories” to try and make them fit into one iteration. The major issue with this approach is that in a lot of cases, the completed stories could not be properly tested or demonstrated as they consisted of only low-level code changes. It also meant that they could not be properly prioritised by our non-technical product owner.
To solve this problem we are trialling a new three week iteration length. We’ve completed two so far which have gone pretty well. The rest of team like the perceived reduction in overhead, since our planning and review meetings are further apart. We haven’t really had an example of a much larger story yet, so I guess we’ll need to wait and see if we have really solved the “dev story” problem.
