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

Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project.

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. 

Conclusion

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. 



Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not
Read more