The advantages of One Week sprints

2 week sprints are boring.  Been there, done that.  So many teams starting out an agile project, especially in a team new to agile, select the default 2 week sprints without really knowing why.  Not that I’m against 2 week sprints, but the biggest part of selecting a sprint time box is knowing why you are selecting that, e.g. What is the value?  (BTW, I try at all costs to avoid 3, 4, 6 week sprints)

One of the big advantages of the practice of time boxing feature work (sprints) is to have a clear end point that is not very far out, so that we can see the finish line often (small batch sizes), and when we reach it determine if we are still going the right direction (inspect and adapt).   Determining what this end point should look like and how often we should inspect/adapt is a difficult skill to obtain.  We as humans are really, really bad at predicting the future, and the farther out we go the worse we get at it.  Especially for a team new to this practice.

My MO when coaching new agile teams is to encourage the team to start with one week sprints.  There is often a lot of concern and push back from this, with the usual arguments “we can’t get anything done in a week” or “it takes too long to deploy to do it once a week”.  The answer to those concerns is that if you can’t do this in one week you won’t be any better at in two weeks.  These objections are always symptoms of underlying problems, such as the deployment capability is not utilizing continuous delivery practices.  Getting a team to work in smaller time boxes will force them to learn to work in smaller increments, which is a core skill they need to obtain.  Learning how to break up a story into the smallest business value they can will strengthen the team’s ability to deploy business value more often, striving towards a daily (or more frequent) change to production. 

In doing initial training I have sometimes put teams in a one day sprint pattern.  Start the day out with deciding what we need to accomplish by COB that day, and set about doing it.  It becomes glaringly obvious where the issues are in the code base, deployment, and product vision/understanding as the team struggles to break down the features into something tangible and deployable in one day.  Sticking with this results in, at a minimum, a team that understands how granular we want to work, and usually provides a pretty good list of spikes to resolve to improve the deployment process.

My motto has long been: if you can’t succeed with one week sprints, you will be terrible at two week sprints.  The problem is, the larger the time box the more the weaknesses in the team and the process will be masked.  Agile is very much about constantly inspecting what we have done and adapting for what we still need to do.  The larger the time box the less agile we become.  Try to succeed with one week (or smaller!) sprints before moving on.   And, as always, if you want to change this practice make sure you understand what problem you are trying to solve by making the change.