The Four Reasons to Have a Consistent Sprint Length

An agile team should maintain a consistent sprint length. Unfortunately, when I first began doing iterative and incremental development (even a bit before doing what today we’d call agile development), I made the mistake of not having all of our sprints be the same length.

We would meet at the start of a sprint to plan the work of that sprint. One item on the agenda of those early sprint planning meetings was to decide how long that sprint would be. We would bounce around in a seemingly random manner between lengths of two to six weeks.

We would make the decision about how long each sprint should be based on how big we felt the work was, how much of it we needed to deliver before our users could see it, who was planning to be out of the office, and how energized or tired we felt.

Allowing our sprint lengths to vary seemed right at the time—and I have to admit it wasn’t a conscious decision; we just did it without ever discussing whether it was a good idea. It was later that I discovered the four reasons for using the same length every sprint.

Teams Benefit from a Regular Rhythm

First, teams benefit from a regular rhythm. When sprint lengths vary, team members are often a little unsure of the schedule. “Is this the last week?” and “Do we ship this Thursday or next Thursday?” become common questions. Having a set sprint length--whether that’s one week, four weeks, or somewhere in between--helps teams settle into the rhythm most suited to them.

Sprint Planning Becomes Easier

A second reason to use consistent sprint lengths is that sprint planning become easier. As a team runs sprints, team members learn how much work can fit successfully into a sprint. Planning the next sprint then becomes as simple as selecting about the same amount of work.

Tracking Velocity Is Easier

When sprints are the same length, it is easier to track velocity. When a team varies its sprint length, they either have to note each sprint’s length (to explain why longer sprints had higher velocities) or normalize into something like velocity per week or velocity per day.

Unfortunately, there is no guarantee that a four-week sprint will complete exactly twice as much as a two-week sprint. Normalizing velocity to be velocity per week works somewhat but is needless extra work when sprints are kept the same length.

It’s What Richard Feynman Would Do

A fourth reason to keep sprints consistent is that it is what Nobel Prize-winning physicist Richard Feynman would do. In his book Surely You Must Be Joking, Mr. Feynman, he recounts the story of getting tired of having to choose what to have for dessert each evening. From that point on, he resolved he would always choose chocolate ice cream.

Choosing a sprint length at the start of each sprint is a waste of energy. Experiment with a couple of lengths, make a decision, and stick with it until there is a significant reason to change.

Can a Team Ever Change Its Sprint Length?

In stressing that your sprints should all be the same length, I am not suggesting you become obsessive about this. No guideline such as this needs to be turned into an unwavering rule. There may be occasions when it would be best to deviate slightly from this schedule.

Long holidays are sometimes a good reason for a team to change its sprint length. For example, in the United States, it’s common for people to take extra time off around Thanksgiving and Christmas. A team that routinely does two-week sprints may find itself with half the number of person-days during a sprint that includes one of these holidays. In that case, the team may benefit from a three-calendar-week sprint, as this would yield closer to the usual number of person days.

Another example could be a team that is approaching a major milestone that would occur, say, one week into the next sprint. Such a team may very reasonably choose to simply plan a final sprint that is one week longer than a typical sprint.

Changing sprint length even in these situations is usually not my preference, but I understand why a team might choose to do so.

What Has Your Experience Been?

What has your experience been with changing sprint lengths? Does your team change sprint length--if so, has that been a good or a bad thing? If you try to maintain consistent lengths, do you ever change? When? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.

If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.