A deeper understanding on…

The Sprint Length

Road to Mastery — Season 2 — Episode 1

With thanks to Willem-Jan Ageling and roland flemm!

As we continue our journey further down Scrum’s wonderland, having learned that much is not what it at first appears, it is perhaps time to now focus on the details surrounding the details.

“Why, sometimes I’ve believed as many as six impossible things before breakfast.” “Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.” “Would you tell me, please, which way I ought to go from here?” “That depends a good deal on where you want to get to.” ― Lewis Carroll, Alice in Wonderland

Oh, but if you want to freshen up your understanding of the Sprint first, why not jump back in time real quick .

Tick Tock Time Box

There are guidelines in Scrum that can help determine a good Sprint length. Now the only way to truly establish what Sprint length works best, we embrace empiricism. We’d have to simply experience it first. This involves inspection and…. adaptation.

“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” from the Red Queen’s race, Alice in Wonderland.

A Sprint should not be longer than a calendar month.

“Each Sprint may be considered a project with no more than a one-month horizon.” The Sprint has “a time-box of one month or less”— The Scrum Guide, emphasis added.

Thankfully it is easy for me to explain why this is as the guide enlightens us with a motivation. A shorter Sprint enables increased predictability, recuses complexity and risk. It increases opportunities to inspect and adapt.

“When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.” — The Scrum Guide

It is long enough the Development Team is confident it allows them to develop an Increment they consider “done”.

“Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.” — The Scrum Guide

The Increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. Supporting empiricism involves the ability to inspect and adapt. Without being able to inspect and adapt the most important artifact, the Sprint has no *umpfh* at all. A Sprint is an iteration in Incremental Development. There is no Incremental Development without the Increment. If the team cannot get to “done”, a shorter Sprint cycle will only slow them down.

It is short enough to be able to adapt timely to changes in the market and needs of stakeholders.

During each Sprint Review the Scrum Team and Stakeholders:

“Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next;” — The Scrum Guide

So if the length of a Sprint is too long, it may very well be that the team learns is has missed opportunities during the Sprint Review. Now, and this should go without saying, alas… The Sprint Review is naturally not the only time during the Sprint during which team members can inspect and adapt to changes in the marketplace. But those reviews generally are the type of get-togethers between the whole Scrum Team and stakeholders which rarely occurs during the Sprint itself.

It is best not to change the length during a development effort.

Please take a short moment to pause and appreciate how carefully the next line is phrased:

“Sprints have consistent durations throughout a development effort.” — The Scrum Guide

So, what is this definition of ‘a development effort’? what about Sprint Events? are they considered to be part of that development effort?

Now, what about ‘consistent durations’. Consistency means it is marked by harmony, regularity, or steady continuity and it is free from variation or contradiction.

Now if we read this, how are we to go back to embracing empiricism in order to be able to establish what a good Sprint length is? If we keep changing it, it is no longer consistent… is it?

Please take this to heart:

“A revised Sprint length may be an outcome of inspection and adaptation, though its short-term consequence would be to make inspection and adaptation harder.” — Ian Mitchell.

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

Aha. So indeed it can make sense to adapt the Sprint length, it is best not to do so during a development effort involving the ongoing Sprint.

Although there will be no Scrum Police to pull you over and fine you if you rebels decide to do so, a good Scrum Master should at the very least explain that in doing so complexity may rise, risk may increase whilst predictability decreases.

Adaptation

So when can an adaptation be considered responsible? The coaching cliché would be… ‘it depends’. Yet here are some common scenario’s and some universal advice:

Scenario 1: “We cannot finish the work, so we increase the sprint length.” -Don’t adapt. Why? The Sprint’s time-box is not a ‘deadline’. Treating it so will send the team on to death marches. Through each iteration, the team will learn what it can or cannot do and becomes more reliable over time. The work in the Sprint is adaptable and can change by the day, this enables the team to respond to change, whilst still remain focussed on achieving the Sprint Goal.

Scenario 2: “We are consistently not able to deliver a ‘done’ Increment each Sprint. -Don’t adapt, unless as a last resort. Why? There is likely an underlying impediment. That should be addressed.

Scenario 3: “We are not ready for release, let’s extend… ” -Don’t adapt. Why? Scrum does not mandate release at the end of a Sprint. Scrum Teams can release whenever it makes sense.

Scenario 4: “It’s not good enough for the Sprint Review. Not every item is “done”. Let’s add a couple of days to the Sprint.” -Don’t adapt. Why? Openness. The Scrum Team and its stakeholders agreed to be open about all the work and the challenges with performing the work. It is required to establish trust. If the Sprint Review were to be postponed, transparency is reduced and an opportunity to timely inspect and adapt is lost.

Scenario 5: “We’ll reduce the Sprint length because we already achieved our Sprint Goal.” -Don’t adapt. Why? A Development Team can still work on non-Sprint Goal related items and work on its improvement plan. Due to the short duration of Sprints, the complexity introduced by changing the duration near its end is often more wasteful than if the team simply sticks to its time-box.

Scenario 6: “We’ll reduce the Sprint length because we are consistently meeting our Sprint Goals and believe we can continue doing so with an even shorter interval.” -Yes, consider adapting. Why? A team that is consistently meeting their Sprint Goals is a healthy sign. If they believe they can continue doing so in shorter intervals, there will be more frequent opportunities to inspect and adapt.

Scenario 7: “We can now reduce Sprint length due to automating regression testing” - It depends. Why? It appears the Development Team has, through automation, enabled regression testing to be performed at speed. They are now confident to get to “done” faster.

Rigidity and absolutism

Some will argue that the Sprint lengths should remain the same length always. Period. Although there is value in keeping a Sprint length consistent, and indeed variations will introduce risks, Scrum surely does enable teams to responsibly inspect and adapt. Naturally, a Scrum Team could responsibly break a rule, as long as it considers the empirical pillars and Scrum’s values. The result of a changed Sprint length is still Scrum. And in Scrum, there are no enforcers, not even the Scrum Master… who should only ‘encourage’.

Shipping Frequency fallacy

It is not true that the Increment can only be shipped at the very end of the Sprint. Scrum Teams can ship as often as they decide during a Sprint. Scrum Teams work, ship, plan on a daily basis. Scrum Teams can:

“Release products and enhancements, as frequently as many times per day” — The Scrum Guide.

“But what about the Sprint Review?” Alice might be wondering “surely one should not release if it has not been reviewed?”. Well, Alice… why do you believe individual items can not be inspected as the Sprint progresses?

Though indeed the Sprint Review is at the end of a Sprint, it serves to figure out what to do next. Inspections, involving the review of work, can be done numerous ways which enable it to be deployed well…almost instantly after its development. And what if I told you it could be inspected even before it existed with a very special kind of Tea? “Tea?” Alice asks… Indeed Alice! the “T” for Test. TDD.

“Tea Dee Dee? now you completely lost me” Alice sighs.

“Take some more tea,” the March Hare said to Alice, very earnestly. “I’ve had nothing yet,” Alice replied in an offended tone, “so I can’t take more.” “You mean you can’t take less,” said the Hatter: “it’s very easy to take more than nothing.” — Alice in Wonderland.

Can you ‘CI’ Alice? “Don’t you mean ‘see me’?!” Alice replies, “Yes of course I can see you”. Well, how about ‘CD’? “No, who is this Dee?!” Alice frowns.

Who establishes the time-box?

This, sigh, is not specified in Scrum as so much else is left up to its practitioners to figure out. And yeah, naturally that is what makes Scrum so damn awesome as well. But if I may introduce a suggestion: We established the guidelines for a good Sprint length: it requires both an understanding of what can be “done” and how demanding the adaptable market might be. So the length is perhaps best established in alignment between the whole Scrum Team and (likely) some key stakeholders. So it can be worth revisiting the Sprint length during Sprint Reviews if inspections call for adaptations.

The Heartbeat

As the heart of Scrum is a Sprint, its cadence can be considered its heartbeat. Although changing its rhythm and pace is possible, only do so if it’s considered healthy. If your Sprint Cadence is highly unstable, I reckon that ultimately the product will be too.

The Sprint as a lesson.

We’ve established that the Sprint length is of major influence to a team’s agility. I’ll argue that with shorter Sprints there is less risk that the definition of what is being built may change.

“A Sprint should be as short as possible but no shorter.” — Ken Schwaber

There is less chance complexity will rise, or risk will increase. In general shorter Sprints tend to optimize predictability and increase opportunities to inspect and adapt through each increment. But a team may not always be ready for shorter Sprints.

“And how many hours a day did you do lessons?” said Alice, in a hurry to change the subject. “Ten hours the first day,” said the Mock Turtle: “nine the next, and so on.” “What a curious plan!” exclaimed Alice. “That’s the reason they’re called lessons,” the Gryphon remarked: “because they lessen from day to day.” —The Mock Turtle’s Story. Alice in Wonderland.

The Road to PSM III is being reformatted to The Road to Mastery! Part I: Down the Rabbit Hole is now available.

Next episode:

Do you want to share an article in Serious Scrum? Connect with us and make it happen!

Also, you’re all invited to the Serious Scrum Slack workspace. Come join the conversation!