Sprints are like loan terms; the shorter, the better. Extending the duration will increase the costs but not the benefits.
The Scrum Guide defines “Sprint” in the following way:
“They are fixed length events of one month or less to create consistency.”
The third principle from the Agile Manifesto takes a similar stance:
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Though both establish a maximum, neither is overly prescriptive in the exact length you should choose. The Agile Manifesto does obscurely state that the shorter period is preferred but doesn’t elaborate on why.
This article will demystify the Scrum Guide omittance by elaborating on the benefits of shorter Sprint lengths.
When I was a kid, my family used to go on vacation every year. We didn’t do anything too grand, mostly sightseeing in neighboring states, but it was something I think the whole family looked forward to.
Back in those days, smartphones and GPS systems weren’t commonplace. We had to rely on the handy dandy atlas, or if we were in a pinch, we’d pick up a map from a local gas station.
One year, my dad took a wrong turn. My atlas-holding brother tried to correct the mistake, but Dad wasn’t willing to listen. When we finally stopped to ask for directions, we’d driven 200 miles in the wrong direction.
If we’d attempted to verify our course sooner, we could have saved some time - not to mention gas money. Frequency check-ins can determine if course corrections are needed sooner and reduce back-tracking.
The end of each Sprint is a perfect opportunity to stop for air and have a logical discussion about our current trajectory. Are we heading in the right direction, and do we want to keep going? Shorter Sprints mean more opportunities to align to our course or change our destination if it no longer makes sense.
How do you eat an elephant? One bite at a time.
Larger features almost always benefit from being broken into smaller chunks. Smaller pieces are easier to handle and push through a process. Smaller scopes mean that each step between starting something and finishing it has less to do. For example, think of QA. Verifying changes to three lines of code is more manageable than verifying hundreds of lines.
Minor improvements are also easier to remember than larger ones. We started the Sprint by discussing everything in Sprint planning. Three big, complicated changes are more challenging to juggle than ten smaller, simpler ones.
Another positive side-effect of limiting scope is that it improves focus.
An agile team will be able to get less work done in a one-week Sprint than in a two-week Sprint. Thus, the development team brings in fewer Product Backlog Items from the beginning when working in shorter iterations. With fewer items in the queue, the team will naturally focus on getting things done vs. starting more work.
In essence, short-duration Sprints act as a natural WIP limit.
There is a reason why most weather apps only forecast two weeks at a time. The further out they look, the less accurate the predictions become.
It’s common for someone to give a two-week notice when they leave a company. If a team member announces their resignation at the beginning of a one-month Sprint, your whole four-week plan will be shot. But, if you’re doing shorter Sprints, you have an opportunity to replan right as their leave takes effect.
With Shorter Sprints, your ceremonial meetings also become shorter as they should be proportional to your Sprint duration.
If Sprint Planning is four hours for two weeks, it should only be two hours for one week.
Some teams prefer the frequent coordination of shorter, focused meetings vs. longer meetings covering more scope.
For some inexplicable reason, my husband and mother-in-law insist on cooking via the feedback cycle method. They put something in the oven and then just on it intermittently until it’s done.
My mother-in-law will put biscuits in the oven and anxiously hover by the door, checking every couple of minutes to see if they’re “golden brown.”
My heartmate’s assertion that she used the smoke alarm as an oven timer when he was a kid might intensify her overly cautious nature.
On the other hand, my husband once put a pizza in the oven and returned to playing a video game while he waited for it to cook. Distracted by the game, the unchecked lunch completely slipped his mind.
By the time he remembered and ran to the kitchen, the only thing that remained of the pizza was a charred husk. It was rather odd; the color had drained from it, leaving it to resemble a piece of charcoal.
I question why neither of them chooses to use a timer. Still, that obvious inquiry aside, I must admit my mother-in-law’s golden brown biscuits win over my husband’s charcoal pizza.
In his book Scrum Field Guide, Mitch Lacey perfectly describes the benefits that short iterations have on the feedback loop:
”[T]he whole purpose behind the one-month-or-less sprint length is the feedback loop—validating that the path the team is on is the correct one. Another way to put it is that in the beginning of the Sprint, the team heard what the product owner (and the stakeholders) asked for. At the end of the Sprint, the team presents what it thinks it heard—essentially trying to prevent what I call the “what I meant syndrome,” when customers and stakeholders say after a sprint or release, “You built what I asked for but not what I meant.” This situation plagues so many teams, why would they not want shorter feedback loops?”
The Scrum Guide defines the Sprint in the following way:
“Sprints are the heartbeat of Scrum, where ideas are turned into value.”
At the end of a Sprint, a Scrum Team should have a potentially shippable increment. The team typically demos the product Increment to stakeholders.
One of the benefits of the activity is that the customers see progress each Sprint. If your Sprints are one month each, they’ll see progress twelve times a year. If your Sprints are two weeks each, they’ll see progress twenty-six times a year.
If you assume that the development team would adhere to the same Product Vision at the end of the year regardless of sprint duration, then getting the product releases sooner rather than later is the better option. We have an opportunity to reap the rewards of each increment as it is released.
A common complaint of Scrum is that the team locks scope during the Sprint. This fixed scope allows them to focus on the Sprint Backlog, which they determined in Sprint Planning, and the team strictly avoids unplanned work.
This short freeze can be hard to swallow in cultures that are weak in planning or have a high rate of change.
It gets easier the shorter the iteration. Few things can’t wait a week, but asking someone to wait four weeks is a harder sell.
The Sprint Retrospective is an integral part of any agile approach. Unfortunately, it may be harder for teams with longer iterations to remember the relevant things that happened near the beginning.
The same is true of Sprint Planning. Given that it happens at the beginning of the iterations, the further we get from it, the less we will remember what we decided or discussed in the meeting.
Thus shorter Sprints help us remember all we need to amplify the value of our ceremonies.
Some inefficient processes can fly under the radar when there is enough buffer time to reduce their burden. When a team shortens its Sprint, these inefficiencies become increasingly apparent, and eventually, the team will be unable to ignore them.
With shorter Sprints, you’ll be more protective with your time and less likely to let even the smallest of wastes continue unchecked.
Shortening your Sprint to two weeks or less can have significant benefits, whereas lengthening your Sprint can have hidden costs.
Shorter sprints offer better opportunities for improvement, increase focus and transparency, reduce scope, increase plan adherence, and provide more opportunities to replan.
Like a loan, if you keep your term short, you’ll avoid paying extra costs at the end.