Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, New Practitioners, Scrum
How to decide on Sprint durations?
How does one decide on a sprint duration?

I've been told that once decided, a sprint's duration should be standardized for effectiveness, such that even if you're unable to complete the deliverables for the current sprint, it can still be pushed to the next.

Yet, I've also been told that there is no set duration for a sprint, which can range from days to weeks. In Scrum it seems, it's usually 1,2 or sometimes 3 weeks.
Sort By:
Jonathan -

The Scrum guide advocates 1-4 weeks, and the Manifesto encourages shorter time boxes.

As teams mature, they might decide to reduce sprint duration (between releases or projects) to deliver value sooner and to get feedback sooner.

You could adapt Scrum for different contexts with timeboxes smaller than a week but at some point, the overhead of Scrum ceremonies might become an impediment.

In general, we shouldn't be changing sprint durations on an ad hoc basis otherwise you lose forecasting benefits for short time horizons.

In terms of how the initial duration is set, I've seen a few different flavors:

1. (Ideal) The team discusses what would be short enough to create a sense of urgency and focus but still long enough to be able to complete "something" of value.

2. They start with a default or look at another team and go with their duration - 2 weeks is the most common sprint duration.

3. The duration is imposed either by the organization or by a program team to ensure there is synchronization in sprint duration and cadence.

Great advice from Kiron. If your team are inexperienced or aren't sure then I'd suggest they go with one week or two weeks maximum to start with. Short iterations are better for an inexperienced team because they can fail fast if they make mistakes in planning and estimation.
Generally, the sprint duration is decided upon at the program level. Not much science behind it, but remain b/t 1-4 weeks. There is consideration to the maturity of the organization and team, as well as the product being produced or type of work.

Most seem to fall at the 2 or 3-week cadence. One week is very accelerated, for more mature teams, and better suited for work that allows for rapid efforts and inspection. On the other end of the spectrum, a 4-wk cadence introduces unnecessary risk with larger gaps in the inspection cycle.

Once a cadence is agreed upon, it is best to remain true to that for consistency. Like Kiron mentioned, metrics and forecasting would be 'voided' with frequent change. Additionally, if the team feels they need to change the length of the sprint on a regular basis, probably some other things going on that deserve attention.

It is okay for a team to decide to change their cadence overall, though, would be done with some rational justification. Again, going b/t the 2 and 3 week cadence is less of a 'change'. When we speak of a 1 or 4-week cycle, additional consideration should be had.
You are asking for the Holly Grail (hehehe). My recommendation is do not ask for Sprints, as for iteration duration. But if you are asking for spints, beyond the great comments above, take a look to Mike Cohn´s work.
Great insights, thank you everyone!

Please login or join to reply

Content ID:

"Nobody can be exactly like me. Even I have trouble doing it."

- Tallulah Bankhead