My clients get some very strange ideas about how to choose sprint length. Some seem to think it is extremely important that all the Scrum teams at their company do sprints of the same length. They might even go so far as to make all the teams start and end their sprints on the same day. Not only is that not necessary and usually not optimal, but it can actually cause more problems for teams by creating bottlenecks.

So, how should a team choose sprint length? A good place to start is by considering the project or work that they are doing and mapping it on a Stacey Diagram:

Requirements
	Technology

 

Stacey Diagrams come from the world of complexity theory. The idea is that you should be able to take any project and map it on this diagram, based on its risk level in a couple of areas. Where it lands on the diagram should give you some clues about how best to manage it.

 

Projects that have very low risk in technology and high agreement in requirements are actually ideal for waterfall. This is typically going to be a project that the team has done many times before and, as an added bonus, the requirements are known up front and really don’t change much.

But as more uncertainty creeps into a project, so do more unknowns. Waterfall, which uses a predictive model of risk control, is no longer a good choice. Instead, a framework like Scrum – with its empirical approach to managing risk – is a much better option. By working in short iterations with regular inspect-and-adapt points, teams can fold in emerging requirements as they arise.

So how does this affect sprint length? In general, as a project moves to the right and up on the Stacey Diagram, sprint length goes down. Why? Because as a project moves in that direction, it means there are more unknowns – and unknowns translate to emerging requirements. If a project is getting lots of emerging requirements, it needs a short sprint length to be able to fold them in regularly. The last thing you would want in that scenario is a 4-week sprint, where you are potentially waiting 20 working days to fold in new requirements.

Some of my clients like to put all their teams on the same sprint length – usually two weeks – because they find it helps coordinate releases. That could work for most of your teams, but never force a team into a sprint that long if their work is mostly emerging requirements by nature. A good example of this would be a typical Operations team in an IT department. Much if not most of their work is going to be dealing with emerging requirements, often in the form of fire-fighting (i.e., dealing with emergencies). Ops teams usually do best with one-week sprints and, even then, they should make sprint commitments keeping in mind that a significant portion of their work capacity will be dealing with emerging issues.

In sum, there is no need to force all Scrum teams to use the same sprint length. A better course of action is to consider the kind of work they do and the frequency of emerging requirements before choosing sprint length. The 2-week sprint length is popular because it provides enough time to get a significant amount of work done while giving a nice, regular cadence to the sprints. But never force a team that has a high volume of emerging work into a sprint that long, because you would be setting them up for failure.