Why you shouldn’t use sprint as a name for an iteration

In agile development, especially the scrum approach, we often use the term “sprint” as a basic unit of time in order to measure each stage of the development process. As a definition of time, however, it really does a disservice to developers because the word itself evokes the sense of constantly doing things as fast as possible. Depending how the team is managed, a sprint can be anywhere from one to four weeks–it just has to be a timeboxed effort–but attaching the word “sprint” to every stage, instead of calling it an iteration, can have a detrimental effect on a team over time.

The Negative Connotations of “Sprint”

When it comes to sprints, it’s not the length of time that’s the problem, but the use of the word altogether. As mentioned above, the word “sprint” makes you think of doing something really fast, running headlong towards your goal. This might seem like splitting hairs, but we only need to look at the theory of linguistic relativity to see how calling each iteration a sprint can be harmful in the long run. By holding to the concept of extreme programming all the time, it becomes more and more mentally and physically draining to maintain that mindset. Eventually, you and your team probably start to feel exhausted and overextended towards the end of a project, right?

Sprinting is Necessary, But Not All the Time

That’s not to say that we should do away with the term “sprint” completely. Rather, we should call each stage an iteration instead of a sprint, which is a much more neutral term, and then save sprinting for those times when the team really needs to put their efforts into overdrive. For example, we need sprinting for right before a release date when we know exactly what’s left before the project is finished. We also need to sprint if there’s only a few weeks to go before a trade show and we want to ensure an effective software demo. In the beginning stages, however, we should be looking at the development process as a series of iterations, giving our team the mental breathing room to work at a more measured and sustainable pace.

Seth Godin has a great example in his book, Linchpin, of when sprinting is necessary and why it’s short-lived by it’s very nature. In his example, he talks about trying to launch a major brand of computer games, but at one point was faced with the prospect of the whole project falling through. He spent 20 hours completing the equivalent of six weeks of work in which he thoroughly redesigned the entire project and its launch schedule. The resulting business plan helped him convince the board not to scrap the project, but it was also a burst of effort that was really only possible in that particular moment under those circumstances.

Agile Needs Both Iterations and Sprints

Sprinting has its place in agile because it helps us overcome our fear of doing something wrong since we only have so much time to get it done period. Moreover, sprinting compels us to keep moving forward without worrying about the minutiae that would normally force us to stop and weigh the pros and cons of certain choices. However, we do need to stop and think sometimes; so although sprinting is an important tool in scrum and agile development, we can’t sprint forever. Instead, we should think about each timeboxed stage as an “iteration,” thus giving ourselves the ability to slow down psychologically, even if it’s still the same period of time when all is said and done.