The case for a 4 week sprint
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.
|Image is taken from scrum.org|
Let's break some arguments:
1. Sprint length is not equal to the speed of delivery
There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all the way up to production. So even if you wait until the end of the sprint to 'mark things off', value has been delivered already without relation to the duration of the sprint cycle itself.
2. Time spent on ceremonies
Another aspect is the meeting-to-work ratio for a 2 week period vs 4 weeks. SCRUM has multiples ceremonies, like sprint planning, retrospective, review & grooming, that involve many team members. If you assume only 4h per person during a 2-week sprint, a team of 10 will be spending 40h on ceremonies, that's more than 960h in a year. Moving to a 4-week sprint will reduce that by 50%.
If you need to put a dollar figure, well for a 50$/hour average, that would be $48,000 in a year.
3. Focused weeks, less technical debt
Inspired by the Microsoft team developing Visual Studio Code, I added the "endgame" week at the end of a 4-week sprint. Here is the plan:
- Week 1: Consolidate sprint plan, start working, identify problems delivered in the last iteration.
- Week 2: Work.
- Week 3: Work.
- Week 4: Endgame! Manual tests if needed, documentation, release preparation, final touches for non-automated deliverables, release.
Having the last week of the sprint to consolidate the work reduced technical debt, adding or improving documentation, tests, release process plus bug fixes. As an added bonus, reducing the number of meetings helps developers keep a cleaner schedule, less context switching that translates into more productivity.
With the "no silver bullet" in mind, these modifications to our method increased the productivity of the team and the quality of the artifacts produced. These results might vary for your team configuration, company culture, and product type, but I hope I gave your some insights on a different path to experiment with your team.