Agile Scrum Sprint Length: What's Right for You?

Two weeks is the standard, but a different length might be better for your team or project. This set of variables will help you choose.

Scrum sprints are timeboxes that provide the team with a measuring checkpoint for gathering information about progress and making adjustments to scope, staffing, forecasts and other variables. More frequent checkpoints lead to a more efficient process more quickly. When a team begins a project using the Scrum approach, one of the first questions that often arises is, “how long should our sprints be?”

Scrum experts say a sprint can vary from one to four weeks, depending upon the project and the team members involved.

Teams new to Scrum commonly pick a timebox at the longer end of the scale because they don't understand how they could perform design, development and testing within a shorter period. Their thinking is, if they have more time, they will be able to accomplish what they commit to. Perhaps they would like some padding, or they lack confidence in their ability to deliver in a shorter amount of time. Perhaps they are not sufficiently insulated from the enterprise and have many dependencies on outside teams that cannot respond quickly. (“The DBAs have a 36–hour SLA, so we'll need to wait.”)

The perception that moving to longer duration sprints will reduce pressure and provide breathing room without a cost is a “false truth.” Indeed, it may provide breathing room at the cost of team velocity. People will adjust to fill whatever time they have been given. In fact, the smaller the sprint duration, the faster the engine can run. Smaller durations squeeze out the fat and can only run lean.

The commitment. An argument for shorter duration sprints is the issue of how the team handles the absence of a key team member. The general rule is that the team acts as a unit and must pick up the slack to meet its commitment. In shorter duration sprints, when a team member is absent, teams are more likely to complete the sprint with the original scope than de–scope it.

The unbroken thinkstream. One consideration for longer duration sprints is that software development requires a level of creativity that cannot be rushed. If the team performs one–week sprints, it has only three actual work days – the first day is spent for planning and designing, and the last day is spent on the review and retrospective. On longer sprint durations, say four weeks, the team has 18 unbroken days for the team thinkstream.

However, the reality of human nature is that the same thing is going to happen at the end of the three–week iteration that happens at the end of a shorter one: Time allocated for testing and preparing for the sprint review will be squeezed. The solution is to reduce the amount committed to, break the stories into smaller tasks, pick up more stories opportunistically, deliver functionality earlier in the iteration and allocate time to test and prepare for the sprint review from the start.

The story creation debacle. Another consideration is the time it takes to flesh–out an epic into a family of fully developed stories and document the subtasks. Some topics require lots of time and may need several “reviews” before the acceptance criteria for a family of stories is ready. You must recognize that some complex stories will need more than one sprint to complete. Instead of moving the sprint review, it is better to extend the time to create that family of stories across sprints.

The two–week (10 day) sprint duration has the best balance of all the above factors. It allows for eight days of unbroken think–stream, and provides a near–term deadline that kills procrastination and forces developers' challenges to the surface more quickly. Moreover, this approach is often enough to gather feedback from the sprint review and reflect on the process. Finally, it sets a pace for measuring checkpoints twice a month (leadership usually likes that), keeps the pressure up and “feels” like a sprint.

What's right for your project? Consider carefully for what purpose you might deviate from what has become the two–week standard.

The key with longer duration sprints is making them “feel” like a sprint by keeping up the pressure; keeping them lean; making sure the team has challenged themselves; avoiding the pitfalls of procrastination, lack of visibility into developers' challenges and the absence of team members; and allowing story creation to cross sprint boundaries.

The challenge with shorter duration sprints is breaking the stories into small tasks and reassembling them into a unit of work that will be meaningful to the product owner. If the increment produces too small a delta for the product owner to notice the update or change, then your sprints may be too short.

No matter what sprint duration your team chooses, make sure everyone buys in, then run it as lean as you can. Generally, it is better to set the cadence and have the team adjust to it rather than the other way around.

Read the full white paper, Agile Scrum Sprint Length: What's Right for You? (PDF) or learn more about Cognizant's advanced solutions practice.