The question of what should be the ideal sprint length is quite a popular discussion in the Scrum world. Scrum experts rightly avoid prescribing a “one size fits all” solution. Obviously the answer depends on lots of parameters like the nature of business or the formation of team etc.
In the past years, I have worked in 4-weeks, 2-weeks and recently with 1-week sprints with various on-site, offshore or mixed teams; across different software development and solutions delivery companies. For the sake of this article, I will just focus on the sprint length as the sole parameter. First of all, 4-weeks sprints were very difficult to manage and risky. The sprint review meetings are too complex, retrospectives turn to a full-day marathon if not worse, sprint planning becomes a much bigger responsibility. More importantly, if we are doing something wrong as a team, the amount of damage which may incur is much more than a shorter sprint. Equally, if we are doing something nice, it takes a long time until we are congratulated! Even the burn-down charts are so complex that people start to ignore them.
2-week sprint are obviously much more manageable compared to 4-weeks. Team members will have a chance of getting more frequent feedbacks from the relevant parties yet they will also have enough time to deliver some significant achievements. However, retrospectives are still relatively long meetings and people still find it difficult to remember which problems they had some 10 days ago. Planning meetings suffer from the same drawback and it is very easy for the team to misjudge the amount of work to commit to. After all, a lot of things might go wrong in two-weeks time which could prevent the team to complete all the stories they have committed to.
Finally, and possibly more controversially, 1-week sprints are by far the ones I found most practical. Wouldn’t it be great to get a feedback every week to make sure we are developing the right thing in a right way? Retrospectives are short and focused since many team members will remember the positive and negative highlights of the sprint; who wouldn’t remember what they were doing the other week, right(!)? Frequent releases are the other benefit you get for free with a week-long-sprint. Planning meetings are naturally the most accurate too because you will have a better chance of estimating the absence of team members or changing circumstances for the upcoming week, compared to upcoming month. One month is a long time in our world!
Some people might be concerned that the overhead of making the Scrum meetings (review, retrospective and planning) every week would be a bit too much. However, don’t forget that the amount of time you will spend for each of those meetings will reduce proportionally based on your sprint length. My most favourite justification for the 1-week sprint is (yeah you guessed it right!) that you can’t really go much wrong in one week time. Even though it is the team who eventually decides on their sprint length, I sometimes present them my views as summarised above so that they can make a more informed decision.
It might be the right time for Scrum Alliance to update their following diagram and make it “1-4 Week Sprint” to be slightly more inclusive 🙂