[QUESTION] Why Do Scrum Teams Call Agile Iterations “Sprints”?

The Scrum Guide tells us what a “sprint” is and gives best practices around duration and timing, but it says nothing about why scrum teams call iterations “sprints” in the first place.

phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr

This question actually came from a podcast that I listen to called This Agile Life.

John Sextro, Craig Buchek, Amos King, Jason Tice, and Lee McCauley publish this weekly podcast about life as agile coaches and developers.

On This Agile Life episode #64, the topic was Giles Bowkett’s blog post – How Scrum Should Just Basically Die in a Fire. I recently blogged about this same post, but did not comment on Mr. Bowkett’s disagreement with Scrum calling agile iterations “sprints”:

Scrum’s an agile development methodology, and one of its major goals is sustainable development. However, it works by time-boxing efforts into iterations of a week or two in length, and refers to these iterations as “sprints.” Time-boxed iterations are very useful, but there’s a fundamental cognitive dissonance between “sprints” and “sustainable development,” because there is no such thing as a sustainable sprint.

The This Agile Life crew zeroed in on this criticism and mused about asking Jeff Sutherland why he decided to call scrum iterations “sprints”. Fortunately, Mr. Sutherland has a new book out called Scrum: The Art of Doing Twice the Work in Half the Time AND he answered this question:

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

With the origin story in mind, the “sprint” label makes sense for scrum teams:

  1. The goal is intensity:  Scrum teams are laser focused on a sprint goal and work diligently on their sprint backlog items to turn their stories in to working software.
  2. Scrum teams take time to catch their breath: At the end of each sprint is a sprint review meeting. During the sprint review meeting, scrum teams stop to examine the sprint activities, the latest increment of software the team delivered, and the product backlog. The scrum team also conducts a sprint retrospective to examine how the team got to where they are and how they can do things better during the next sprint.
  3. Sprints are short for a reason: Mr. Bowkett is correct when he says that there is no such thing as a sustainable sprint. But short (2-4 week) sprints with time taken to inspect and adapt the work IS sustainable. Not stopping at the end of the time box jeopardizes sustainable pace as does going past the 1 month maximum sprint length.

Inspecting scrum is a great way to become a better agile practitioner. Podcasts like This Agile Life and blogs like Mr. Bowkett’s are great places to help you think about scrum and deepen your understanding about the practices that you use every day. It’s a tip that I’ve given in the past, but I cannot stress it enough as a great way to improve.

In this case, we learned that the label “sprint” is meant to give teams a sense of urgency, but with the intention of taking rest after the intense work it takes to turn sprint backlog items in to increments of software.

Question: What do you think about the term “sprint”? Does it express the right intention, or is it time to go back to “iterations”? You can leave a comment by clicking here.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • As compared to the “distance run” of a waterfall project, “Sprint” is an apt title. As you mentioned Ryan the emphasis is on the intensity that a team must bring to make it different in Scrum. It also brings a benefit of focus too. When we work on projects for six months or a year in a waterfall project our focus is jumping all over the place as we move through the project. In Scrum we focus on the items in the Sprint Backlog for the two weeks.

  • Craig Buchek

    I do like the “rounds” idea for terminology. I do not like the boxing match analogy though; a boxing match is not sustainable — you get really tired after several rounds. And beat up. Although I suppose that’s a good analogy for what happens in real life teams. Rounds of cards would be a better analogy to me.

    I think “sprint” implies lack of sustainable pace. That’s what a sprint *means* in running — running all out and expending all of your energy in a short amount of time, at the expense of being able to run for very long. And the “all out” idea behind sprinting implies that developers should work overtime during a sprint. (Because resting on the weekend is resting, not sprinting.)

    I don’t think the short amount of time between sprints fits the analogy, either. I believe scrum takes 1 day or less for reflection and planning. 1 day out of 10 or 20 doesn’t seem like real rest, when you’ve gone all out for 2 to 4 weeks. I would suspect that a sprinter would need a longer time between sprints than the sprinting itself lasts. Like I mentioned in the podcast, I’ve seen teams take a full week off between sprints for planning. That doesn’t seem efficient for long-term productivity, but it did seem necessary for their health.

    • Hi Craig,
      Perhaps we can look at a sprint as timebox of intense work, BUT – like runners – the scrum team has to stay in their lane (work a normal 8 hour day). This is sustainable.

      I understand your concerns and have lived through similar experiences. However, overtime and developer abuse is not a scrum problem…it’s a bad management problem. Changing the term “sprint” to “round” won’t fix that.

      RE: Downtime – Scrum takes 2 days per 1 month sprint to do sprint planning, review, and retrospective & also dedicates 10% of the teams capacity to backlog refinement. So ~4 days out of a 20 day (1 month) sprint isn’t too bad.

      Thanks for the comments and keep up the great work on the podcast.

  • Ryan, great article. Thanks for the shout out to This Agile Life.

    I understand what you are saying, and where the sentiment comes from. I have an issue with the implementation that I see from management and developers. They run, and run, and run, and I think you get the point. There is no rest, and I see the stories completed towards the end of the sprint at a much lower quality. The team begins to focus on getting out the code at all costs. This causes overtime, bad practices, and cutting corners. This is why I prefer continuous flow.

    While writing this response I had the thought of calling them “rounds.” I think this is a better analogy because the match goes on. It doesn’t constitute and end, but it does say we are going to have a resting period. Not many people run a sprint, and then another and another. They do, on the other hand, have multiple rounds in a boxing match. The thought of having the next round might allow developers and managers to still concentrate on quality, and knowing that the fight isn’t over. It also constitutes a time of rest. Maybe a day or two between rounds? That day or two should not be a weekend. It should still be coming to work, but reflecting, and getting coaching before jumping into the next round.

    • Great points Amos, but won’t the same bad management that botched the Scrum implementation also get continuous flow wrong?

      We all know that if stories towards the end of the sprint are getting rushed and delivered with low quality then the team took on too much work in that sprint. They are also likely violating their definition of done. This should come out in the sprint review. If the developers and management lack the discipline to make this process work, how can they possibly handle the higher complexity that comes with continuous flow?

      Thanks for reading and for your comments!

      • I have not had the same issues with continuous flow and management. The thing about continuous flow is that the focus is at the front pool and if it is emptying. The focus in a scrum sprint is all too often placed at the tail end of the pipe. I’ve not found a higher complexity with the continuous flow work either. In all the discipline comes on making the stories more coherent and smaller, and less about trying to plan “the right” amount of work. Sometimes you move faster or slower and that is ok. It happens in a sprint too. It is the sprint that is mis-planned that causes the rushed work.

        You can still measure velocity in continuous flow. That means planning can still be done, but it changes the focal point of planning to be the beginning of the pipe.

        • Does it take more discipline/skill to slice the stories to a consistent size that allows continuous flow to work?

          I’m also concerned that too much slicing makes the “sprint goal” or big picture harder to visualize. What happens if a team needs to swarm on a feature and it’s been sliced down to the point that swarming is difficult?

          I have not tried continuous flow on a project before so I appreciate you taking the time go back on forth on this.
          Thanks again!

          • I find that in order to get an accurate sprint estimate that teams need to break down stories as small as they can anyway. When a developer says 3+ days it really means, “I have no idea.”

            I find that the splitting makes the goal more focused and allows for more prioritization among these micro features. This makes sure that we are actually working on what is the priority and not adding “extra” to the highest feature while failing to get the second highest.

            Here are two articles I wrote on story splitting. http://dirtyinformation.com/blog/2014/02/02/smaller-is-better/ and http://dirtyinformation.com/blog/2014/02/23/story-splititing-revisitted/.

            I have had no issues where swarming is difficult because something is broken down too small. In fact I find it simpler if it is broken down. It is simpler to add each person to a different story that way.

          • Fair points. I agree that we want stories as small as possible, but I also want teams to have the big picture in mind. Thanks for the links, they were very helpful.

          • Maybe we need a podcast of continuous flow vs sprints?

          • YES! Would love to hear you and your co-hosts thoughts on this fascinating and advanced topic. Looking forward to the next episode!