Development in Scrum happens with iterations or sprints. An iteration is a time-boxed period within which development is done. During an iteration, the team transforms one or more imprecise requirements statements into coded, tested, and potentially shippable software Iterations are a core part of Scrum. They allow for the development team to quickly converge towards building what is of most value to the customers.
The iteration length is typically 2 – 4 weeks. This is not a hard figure. Some teams have iterations that are as short as 1 week and others have 8 weeks sprints!
In this entry, we will be discussing some of the factors that lead to variability in iteration length and what you should be considering as you are deciding on your own iteration length.
Length of the project
Projects tend to vary in length. I have worked on projects that lasted only a month and some multi-year.
Longer projects offer the luxury of a window of correction. That is if after the end of an iteration the client discovers what was built is not what they expected, there are a number of other sprints that are available to the team to correct the issue. Shorter term projects lack this kind of luxury.
Thus the length of a project acts as an important factor in choosing sprint duration. The longer the project length, the longer the sprint length you can afford have. In fact, if you already know how many reviews you want to have, you can derive the length as follows:
Duration of sprint in weeks = Total project length in weeks / number of reviews
For example, if the project is 2 months and you want at least 4 reviews then the duration of the sprint will be
Duration of sprint in weeks = 8 weeks / 4 = 2 weeks
In addition to allowing for more review periods, longer projects can also more easily afford the “costs of iteration”. The costs of iteration refer to the extra time used to facilitate iterative development. This would include such things as:
- Iteration planning
This means that for longer term projects, you can afford longer iterations and associated time costs. For very short projects, the costs can also influence the length since you don’t want to spend all your precious development time on this supporting activities.
Clarity on product and team
Some projects are simple even if they are not easy. This means that it is easy to communicate what is required and changes are not likely to come during the development phase. These kinds of projects are very rare to come across, most projects are messy especially at the beginning.
Thankfully Scrum thrives in the kind of complex projects that exist in the real world. It does this by ruthless application of Palchinsky principles.
First, seek out new ideas and try new things; second, when trying something new, do it on a scale where failure is survivable; third, seek out feedback and learn from your mistakes as you go along.
You see, iterative and incremental development is about generating feedback, learning from it, and then adapting what we are building and how we are building it. Sprints provide teams with the mechanisms for doing this.
Thus the more uncertainty you have in your project, the shorter the sprint should be.
Uncertainty tends to come in two distinct flavors. First one is, what are we building?. This is the product question and relates to meeting the client’s conditions of satisfaction. The second one is, how are we going to build it?. This relates to the team’s development practices. You may, for example, want to run short sprints at first both to quickly show the client what the product will look like and establish the team velocity.
Since for highly uncertain projects the priorities change quickly, shorter iterations ensure that what you are currently working on is what is most important.
At the end of the sprint, the development team needs to do a demo to the stakeholders. Your stakeholders maybe extremely busy or important individuals whose time is hard to secure. In this cases, it may be wise to plan your sprints according to their schedule.
For example, if the executive team meets once every month, it may make sense to schedule your sprints so that a demo day falls on that day. This way the hard work of convening all of them is already done for you.
You, of course, don’t want to vary sprint length from sprint to sprint. Thus you don’t want to unduly sacrifice your process in service of the demo day unless a good synchronization opportunity exists.
What iteration do you think induces more stress, 2-week or 4-week iteration?
I have asked this question to a good number of my friends, the answer is almost always 2 weeks. They are wrong.
It may not seem like it, but longer iterations tend to induce more stress than shorter ones. This is because longer iterations have well defined, beginning, middle and ending points. Naturally, the team is a bit more laid-back at the beginning and gets more stressed as the deadline approaches.
Shorter iterations smooth out this effect, the team can then settle into a manageable tempo.
See this masterful piece by Tim Urban:
How do you select iteration length in your own organisation? Talk to me in the comment section below or on my twitter @ jchex