This post is the latest in Excella’s Dear Agile series of blog posts. Have a question for Dear Agile? Send it to us via our anonymous submission form.
DEAR AGILE –
I’m not a fan of the idea of two-week sprints. An infinite timeline of two-week deadlines seems crazy to me. Why does Scrum have these artificial deadlines, and how can they possibly help us?
— OUT OF BREATH
DEAR BREATH:
It’s true that a deadline every two weeks can do more harm than good. Fortunately, sprints aren’t really deadlines! Deadlines are like rocket launches: there’s chaos if you miss a narrow window of opportunity. But sprints, guided by the Agile principle to “deliver working software frequently, from a couple of weeks to a couple of months,” are more like commuter trains: there’s always another one right around the corner. Though teams should strive to complete the work they’ve committed to, anything they miss needs only wait a couple weeks to be delivered.
And sprints aren’t just intervals for product delivery. Scrum is built on feedback loops – cycles of action, reflection and adaptation – and the sprint is perhaps the most important of them all. Respecting the sprint time box is less about the consequences of incomplete work, and more about the causes. As one sprint moves into the next, Scrum teams explore:
- What they’re working on. The Agile Manifesto tells us to value “responding to change over following a plan,” and we do just that at Sprint Review and Planning meetings. Project stakeholders assess the team’s progress and plan the work that will be done in the next sprint. More frequent sprints limit the damage of a changed or misunderstood priority.
- How they work. It’s easy for teams to fall into a rut with a process that holds them back instead of empowering them. But at the Sprint Retrospective, “the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly,” as the Manifesto puts it. Not only do they get better, they get better at getting better.
- How much they can do. Sprints are short enough to make reliable predictions, but come too fast and furious for a team to enter “crunch time” at the end of every sprint. There may be a few painfully underestimated sprints at first, but before long your team should reliably commit to the right amount of work – per the Manifesto, hitting “a constant pace indefinitely.”
Each of these benefits is enhanced with a shorter feedback loop, but must be balanced against the need for focus and the team’s experience. Two weeks is a good default for many teams, but it’s not the answer to everything. If your team views sprints with the same crushing terror it does deadlines, consider starting with a longer cycle and moving to shorter ones as comfort levels allow.