How to avoid a funky meter?
How long should your Sprints be?
“How long is a piece of string?” is a cheeky answer to the question, “how long will this take?”. But, determining the length of your sprints sometimes can feel as vague, elusive, or funky as answering that question.
How do you avoid a bad cadence, off tempo, or funky meter that doesn’t suit your organizations pace of effective delivery? How to ensure your Sprint length is fit-for-purpose?
Here are three questions I consider when deciding on Sprint length:
1. Can you produce a Potentially Releasable Increment in a month or less?
Finishing Sprints in a shippable state is the capability that help us be agile. Do we have the capability to produce at least one finished, ready-for-customer, increment of customer value? If we can do that in a month, then perhaps a month is a good Sprint length to start with. As we improve our ability to produce completed work by the ends of Sprint, we may shorten it later, if and when, it makes sense to do so. The advantage of shorter iterations is shortening our learning loop.
2. How long can we go before we make changes?
In order to allow the team to be productive and potentially complete the work they planned, can we leave them alone and not make changes for the entire Sprint? If the pace of change in our domain is typically every two weeks and our Sprints are four weeks long, perhaps our Sprint length is out of step with our needed rate of change. Sprint length should reflect a period of time where we are committed to letting the team stick to their plan without adding work or changing direction. For teams to reach a state of flow, they need time to focus and concentrate. Changing direction too often will reduce productivity and effectiveness and cause us to thrash.
Mihaly Csikszentmihalyi
Flow, the secret to happiness
If you want to learn more about flow, check out the work of Mihaly Csikszentmihalyi in his TED talk >>
3. How long can we go being wrong?
A Sprint is a safe-to-fail experiment. How much of a Sprint failure can the organization tolerate. If a two-week failure is OK but our Sprints are four weeks long, we may have a problem. Choose a Sprint length that is a period of time that, if the team completely fails to deliver what they planned, that is tolerable. It’s never great to fail but failure is one of the best ways of learning. Seeing failure as a learning opportunity is an organizational and leadership cultural issue. Organizations that have a high tolerance for failure and focus on learning are more resilient, productive, and innovative. Failing a Sprint is far better than failing an entire project. Fail fast means fail small. Failing small means the cost of recovery is small.
Once you’ve chosen your Sprint length, stick to that cadence for a while. Think of Sprint length as Scrum’s metronome, helping the team learn the tempo, cadence, or meter of Scrum. Just like the fact that you don’t change the metronome mid-song, we don’t want to change the Sprint length until we know and understand that pace.
The only funky meter you should want is this kind >>
If you have other considerations you use to determine Sprint length, please add them in comments.
