Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.
What about a year-long project? Assuming four-week sprints break approximately monthly, that project would offer 11 opportunities (plus the final release) for stakeholders to see the developing product. Four-week sprints are a realistic option, depending on the other factors involved.
If a project is expected to last more than one year, rethink the project. Multiyear projects are too big. Find a way to divide it into shorter releases. Just as you wouldn’t want a two-month sprint, you don’t want a two-year project – divide it into four, six month projects instead. If you find you can’t come up with a way to break the project into smaller components, then you likely have larger cultural issues in your company that should be addressed before you try to use Scrum
The ability of the team to decompose its tasks is critical on short sprints and still important on longer sprints. Decomposing tasks is in and of itself an art form, one that requires critical thinking, a clear mind, and the ability to see beyond the surface of a problem. If your team is good at decomposing tasks (or wants to get good in a hurry), shorter sprints (one-to-two weeks) can work. If your team is still learning how to decompose tasks, you might want to start with longer sprints (two-to-four weeks).
Source: “The Scrum Field Guide : Practical Advice for your First Year”, Mitch Lacey, Addison-Wesley,
In this excerpt of his book, Mitch Lacey provides good advice about the project and sprint duration in Scrum. Some people think that the duration of sprints in Scrum should always be two weeks. If the length of sprints has to be constant during the project, many factors can influence the sprint duration.
Scrum Sprint Perspective. Source: Adaptive Project Management Using Scrum
As mentioned above, the duration of the project is an important factor. Shorter project should have shorter sprints, because the goal of the sprint is not only to deliver potentially workable software, but mainly to get feedback on it and allow adjusting the backlog items and priorities after this feedback. Thus the goal of the team should be to have the smaller possible sprint duration because this allows having more feedback. Other factors like the technical infrastructure, the size of the Scrum team, the availability of its members or the users will influence the duration of the Scrum sprint.
You can also consider the problem with reducing the length of the sprints as an indicator that there might be possible issues with the organization or the Scrum team. Is there a lack of commitment from the end users? Are the team members committed to too many projects? Do the team lack some technical skills that inhibit its ability to deliver workable software at the end of the sprint?
Further Reading
* Agile Scrum Sprint Length: What’s Right for You? (PDF)
* Why sprints and how long should they be?
* Ideal Iteration Length – A Survey
* How long to Sprint?
* What’s the ideal sprint length