An updated version of this post can be found here. Please update your bookmarks and links to the new article. This version will no longer be maintained.
The Agile Atlas (the Scrum Alliance’s Guide to Scrum), provides little advice when choosing your Sprint length, saying only: “A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals.”
It leaves it up the team to decide what will work best for them. These notes are intended to help navigate the tradeoffs involved.
When you’re first starting out in Scrum, it’s reasonable to experiment with Sprint length to find out what works best for your context at that moment in time. There is one caveat: shorter Sprints (one to two weeks) help reveal problems/impediments faster. Sometimes this is uncomfortable; and teams consider longer Sprints again to avoid dealing with these problems. This isn’t a Scrum-like approach; Scrum is intended to bring the problems we have to the fore. Sprints of one or two weeks are short, while those of three to four weeks in length are long.
Longer Sprints (3-4 weeks)
Pros
- It’s easier to start doing Scrum with longer Sprints
Cons
- Difficult to plan well for a three to four week Sprint during Sprint Planning. This leads to more “dark work” [1] being done.
- Related to dark work – new features and needs tend to crop up more often mid-Sprint.
- The Product Owner will have a harder time not asking for change; i.e. new features or stories mid-Sprint.
- Fewer Sprint Retrospectives lead to fewer explicit opportunities to improve.
- Fewer Sprint Reviews give the Product Owner fewer opportunities to improve the product.
- Makes it easier to do “Mini Waterfalls” within Scrum, i.e .Analysis -> Development -> Manual Test, with a certain number of days planned for each.
- Problems tend be discovered and addressed more slowly
- Lack of focus
Shorter Sprints (1-2 weeks)
Pros
- Since the team has more but shorter retrospectives they have more opportunities to try smaller changes. This also provides more opportunities to learn.
- More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to change. This should largely eliminate the need for the Product Owner to ever ask for a change (i.e. new Story) in the current Sprint.
- Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.
- Shorter cycles make planning easier, which increases focus and reduces the amount of “dark work”.
- Forces teams to do a better of job of slicing Stories or Features into smaller chunks. This increases visibility and gives the Product Owner better control over prioritization and deprioritization.
Cons
- It’s harder to get to a finished product at the end of one or two week cycle. Caveat this is true at first however most teams are able to get the hang of it after three to four Sprints.
- Working in one week Sprints can be more stressful at first.
- Overhead – people say that the Sprint Meetings are too much overhead for a one week Sprint. However sprint meetings scale linearly with the length of a Sprint. So a one week Sprint will have 2hrs of Sprint Planning, a two week Sprint have 4hrs and so on.
Today most teams that are new Scrum pick two weeks Sprints. Some go as short as a week.
Coming here 3 years after publication I’m just adding a comment for a different perspective.
Long sprints:
“It’s easier to start doing Scrum with longer Sprints” – can’t say I agree as a general statement. I’m sure the author speaks from experience, although I myself only worked with 2-week sprints (doing mostly web projects) and despite some discussions on altering sprint length, it was never a question of difficulty with the Scrum process. Easy/hard largely depend on experience and the characterisation of long/short is also a matter of perspective.
Cons:
#1 – it’s difficult in the beginning (just like with any kind of planning), which is a reason I wouldn’t consider ‘long’ sprints easier to start doing Scrum. However accuracy comes with practice.
#2 – generally yes
#3 – one of the points of Agile in general is the accommodation of change. Sprint length shouldn’t be used as a way to run away from change.
#4 – number isn’t a measure of quality. Short sprints may (or may not) also mean that the team has less time to observe improvements at work or to observe issues in action. Also the issues may prove to be sprint-length specific.
#5 – opportunities for improvement happen all the time. The PO doesn’t and shouldn’t wait for a full increment to discuss improvements.
#6 – true, mini-waterfalls have a higher incidence rate in this case, but the team can mitigate this by better work organisation
#7 – smaller chunks make sense for smaller sprint length but it may not be a direct concern for longer sprints. This assumes inherently that shorter sprints are a target by cultivating a skill directed at shorter sprints. Slicing is also used anyway when organising the chosen work, so it can happen anyway
And take these and reverse them as counter arguments on shorter sprints.
Shorter sprints also have some extra disadvantages:
1. As a percentage, there will be more time spent in Scrum events, leaving less time for work. Even when work load is adjusted, it will leave the team with the feeling that Scrum event time is wasted.
2. In one week sprints the warm-up/cool-off cycle is reduced. Unexpected work accumulates towards the end of the sprint, increasing pressure then as opposed to sprint start. During a single week (and depending on project type and work type/system, even during two-week sprints) this quick shift in pressure will affect morale leading to irritation over long term.
Finally, change happens even in one-week sprints, the point is to accommodate it, not run away from it. Change happening in short sprints is ill-received also due to having less time to evaluate and negotiate while also handling ongoing work.
Spring length isn’t a general principle, it should be tailored to the people in the team, stakeholders, the type of project and other processes that are used while working.
Austerus – welcome to the conversation. I love having other perspectives.
A few small clarifications:
– When I said “It’s easier to start doing Scrum with longer Sprints” – this wasn’t intended as a good thing. Many teams want to start with 4 week sprints because it allows them to do waterfall inside Agile. In the long run that is neither effective or desirable. Breaking the old cycle is critical for long term success.
– “#3 – one of the points of Agile in general is the accommodation of change. Sprint length shouldn’t be used as a way to run away from change.” – accommodating change in Sprint is occasionally necessary however it happens frequently it points to systemic Product Ownership issues.
– “#4 – number isn’t a measure of quality. Short sprints may (or may not) also mean that the team has less time to observe improvements at work or to observe issues in action. Also the issues may prove to be sprint-length specific.” – not only do we agree but I’m not sure what I would have said to make it seem like I believed otherwise.
The underlying point of the original post – in the general case Shorter Sprints force us to adopt habits that help us improve more quickly. Most of the improvements that it forces us to take on (Story Slicing, Test Early, Test Often, …) lead the other things we value in Scrum.
Agile is to adapt to change, the biggest problem in organizations are Agile evangelists who don´t adapt Agile to the environment.
Oscar – I’m confused as to how this comment applies to the blog post. I don’t tell you what to do, I examine tradeoffs.
Big pro of 3-week sprints: less sprint meetings, less creating demo’s and a better chance to work uninterrupted on difficult tasks for a couple of consecutive days. We moved from two to three week sprints a couple of months ago and no one has even suggested of going back to 2-week sprints.
Seems like this paper was written by an agile pusher. I’d like to see one that truly explains when agile is not the best method for a company to choose. Anyone who is truly looking at overall processes will know that these circumstances exist and work to find the one that really fits the team. For example; what if clients do not update more than once per year? Would a short sprint truly be the best idea?