The more I look at teams that have two-week sprints, the more convinced I am that it is a bad idea. I know this is a controversial stance, but controversy has rarely stopped me from exploring an idea.
So let’s ask these questions: Are two-week iterations really a good idea? Is it a goal all teams should strive for? Is it OK for a company to mandate two-week iterations for all teams? The more teams I encounter, the more I start to see some problems with the two-week iteration, problems that no one seems to want to address.
Don’t get me wrong. For many teams, a two-week iteration is great. My goal here is to help you look under the covers and make sure that your two-week iterations are healthy ones, not ones that cause bigger problems than you might realize.
Below, I explore four points:
Whether it is OK to mandate two-week iterations.
The typical arguments in favor of two-week iterations.
The arguments against two-week iterations.
Recommendations on what to do with this information.
For the rest of this discussion, allow me to define two terms. A short iteration is a two- or one-week iteration, with two weeks being more common. A long iteration is a three- or four-week iteration, with three weeks being more common. OK, let’s dig in.
[ Is it time to rethink your release management strategy? Learn why Adaptive Release Governance is essential to DevOps success (Gartner). ]
Is it OK to mandate a two-week iteration?
I remember when RUP (Rational Unified Process) advocated six- to nine-week iterations, then Scrum came along with its four-week iterations. Since then, many teams have gone down to two. SAFe (the Scaled Agile Framework) also advocates the two-week iteration, but in that case, it is just a suggestion, one that has worked well for most SAFe adopters. Now there are even teams that do one-week iterations!
