Welcome to the fifth installment of my blog series on “20 Controversial Topics of Debate in Agile”. In this blog, the topic of debate is how long Agile Sprints should be.
Well, the Scrum Guide says that anything over a month should no longer be considered Agile. I agree with this. I recently encountered another consulting firm working on a large system replacement project, and they were running 6-week sprints. As soon as I heard this, I knew that they weren’t really operating in an Agile fashion. A month-and-a-half is far too long to go without feedback from stakeholders and customers.
So, what is the optimal length for your Sprints? I’ll give you the standard consulting answer: “It depends”. Well, it does. It depends on the type of working you are doing, how long you can go between feedback loops, how quickly you want to go to market with your MVP (minimal viable product), whether your work is experimental, etc.
Possible Sprint Lengths
Month-long Sprints (or 4 weeks)
As a consultant, I have honestly never seen an organization use a full 4-week or month-long Sprint cadence. From my perspective, that amount of time is far too long to go between feedback loops. Unless someone can make a compelling argument to me otherwise, I would almost never recommend using iteration lengths that are this long.
3-week Sprints
I have seen several Scrum Teams use 3-week Sprint lengths. I feel this is appropriate if your product is extremely complex and there are a lot of moving parts and pieces and/or integrations. That said, I still don’t like how long it is between formal Scrum events, especially the Sprint Review. However, the team should be getting feedback as they develop, not just at the Sprint Review, so this shouldn’t be a problem with 3-week sprints.
2-week Sprints
Personally, my preference is for 2-week Sprints. My reasons for this are that:
- It’s a long enough time period to get significant amounts of work done
- The sooner you can get a product in front of users, the more useful feedback you will receive
- You can find out sooner rather than later if something doesn’t work (fail fast, fail cheap)
- It gives the team a sense of urgency to deliver on their Sprint Goal
- Like Goldilocks, it’s not too long, and it’s not too short, instead it’s “just right”
That doesn’t mean that other Sprint lengths aren’t worth considering, just that I find this to be the optimal length under most circumstances.
1-week Sprints
I can also see an argument for using shorter Sprints. A few years back, one of my colleagues and I performed an Agile Readiness Assessment for a company. We decided that the best approach for the assessment itself was to run it in an Agile fashion. Part of that was just to model Agile to the organization; we ended up having six one-week sprints. It was the perfect cadence for us to make progress and show our results as they were realized. When we delivered the final assessment, nothing was a surprise, and the company could see how Agile delivered transparent results.
1-day Sprints
One-day Sprints might be useful if you are doing experimental or innovative types of things, where you want to see if something is feasible as quickly as possible, and then move on to the next experiment. If you are doing 1-day Sprints, you must obviously adjust your normal timeboxes to scale down for the limited amount of time available.
So… just to recap:
| 1 week | 2 weeks | 3 weeks | 4 weeks (1 month) |
| Not common, but not unheard of This may be the best way to “fail fast” | The most common sprint length, especially for IT / software development work | Second most common sprint length for more complex projects with lots of integrations | Not usually recommended, but also not totally unheard of |
So, which sprint length is best?
That depends on a lot of factors, some of which may include the:
- Size of the project
- Type of work being performed
- Size of the team
- Organization’s release schedule
- Amount of risk involved
- Market conditions
- Etc.
The whole idea of the Agile approach is to deliver the business value as quickly as possible, so it stands to reason that the shorter durations would better accomplish this.
Having shorter Sprints puts pressure on teams to deliver faster. It also gives the team more opportunities to inspect and adapt to improve more quickly.
What do you think?
Now that you know about the different options for sprint lengths, which ones have you used? Which is best for your situation, and why? Do you agree with my opinion that 6-week Sprints are not Agile enough? Drop me a line and give me your opinion in the comments section below!
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can agile co-exist with waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?