How Long Should Your Sprint Be?
The answer is pretty easy if you’re Usain Bolt, but from my perspective many agile teams struggle with the question. The modern answer is akin to The Matrix question — the truth is that there is no sprint, you should be focussed on flow, but there are still plenty of teams using a Scrum-based process who need to agree on some sprint duration, and it seems reasonable to offer them some advice.
The most common answer seems to be three weeks. My answer is that when you’re starting out you should begin with one-week sprints, after which you might want to experiment with two weeks. The most common response I hear to that suggestion is that one-week sprints are simply impossible in that particular team/language/problem domain/whatever.
One-week sprints aren’t impossible, but they may be challenging, and that’s part of the point. Long sprints are too easy to treat as mini-waterfalls, and for many teams that means that the sprint is pretty much like their previous process — big pieces of work that flow through analysis, design, implementation, testing and delivery. Nothing much changes from whatever process they used before. To mangle Star Trek: it’s flow, Jim, but not as we know it.
You can’t get away with that in a one-week sprint, at least not if you want to be able to even pretend that you’ve delivered some increment of working software. A one-week sprint forces radical changes to your process; they may not be easy changes, but they will be rewarding.
You actively need to break your stories into smaller pieces. You’ll probably need to better understand what the larger story is trying to achieve, learn more about the problem domain, and also be creative in the way you split it up. You may discover that some of the small pieces aren’t really that valuable and can be done much later, or possibly not at all.
You usually don’t have time for handovers because they’re time-consuming and they make scheduling and coordination too hard. You’ll find you benefit more from generalists, or from specialists working in tandem (pairing).
If you have separate testing environments, you won’t be able to tolerate time-consuming release processes.
You probably won’t have time for a separate user acceptance phase — you’ll need to involve the user more incrementally so that user acceptance is a formality.
When I’ve helped teams transition to agile in the past, I’ve started them with one-week sprints and told them to expect the first few to fail, in the sense that we won’t deliver anything. What we will do is quickly identify areas of the process that need improvement and act on them. By the end of the third sprint (the equivalent of one three-week sprint) we will have made a number of process changes, and we’ll probably have delivered something as well.
Even if we just stick to the “normal” Scrum ceremonies, we’ll have had three retrospectives in three weeks (we may have had more). We’ll also have had three planning meetings and three showcases (and of course fifteen daily scrums).
At this point in the description, some people are saying “you can’t get anything done with that level of overhead, which is one of the reasons you should favour longer sprints.”
It seems a common misconception that sprint ceremonies are of fixed duration, independent of sprint length. I don’t really know why that’s the case, since the Scrum Guide is pretty clear that shorter sprints imply shorter ceremonies. It’s repeatedly been my experience that once you have practice, the ceremony duration is roughly proportional to sprint length. The caveat “once you have practice” is important — it doesn’t happen right away. And how do you get more practice? You have more ceremonies, by having shorter sprints!
Shorter sprints convey lots of benefits, but I’ve suggested experimenting with two week sprints as well. This is based on personal observation, and I’m not sure how well it generalises — short sprints are demanding, and some teams find that’s not sustainable in the long term. I had one particular team that moved to two-week sprints after a year of one-week sprints because they needed more time to vary their work practices — one-week sprints produced constant pressure, and some people benefitted from being able to vary their personal work intensity over a longer sprint. The metrics showed very little impact on overall delivery and an improvement in team satisfaction.
I encourage everyone to pick up the gauntlet thrown down by shorter sprints — overcome the challenges and see what you can do in a week.
