The case for a 4 week sprint
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaHlSEU5lDIrvOcaJc7wSkaY5V3Tfpb7qyj3uM-zvFf__rU7U175e0pTvuQRxoSoebjeleCvs7KrzQD45zO0h5KWgcfqLn7MN3ynPfly3D9X_jslHewdcVwJGcn7caKHvtzH41/w400-h200/image.png)
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 t...