Get certified - Transform your world of work today

Close

To Sprint or Iterate?

The sprint vs an iteration

23 September 2016


What is the definition of the word sprint? The Oxford dictionary defines it as: "Run at full speed over a short distance" and "An act or short spell of running at full speed." Clearly, the intent here is "running at full speed."

When people hear the word sprint, they think of an athlete with a short-term goal, pushing himself to the limit over a short distance to win a single race. Who doesn’t enjoy watching the 100m sprint at the Olympics? What is an athlete aiming to achieve at each sprint? A sprinting athlete focuses purely on winning a short race, to go as fast as possible in the shortest possible time. Is that the sort of thing we are trying to achieve in software development? The answer is not a clear yes. The answer is both yes and no.

Like an athlete, preparation before each sprint is the key to success. Just as an athlete makes preparations before a race, an Agile Team must prepare for the sprint by engaging in sprint planning with the product owner. The team also needs to set a sprint goal. This goal can usually be summarized in a single sentence and is a clear picture of what the team is trying to achieve each sprint — a target that they can see and keep in plain sight, a target they can aim for and reach in a short period of time. But that is where the similarities of an Agile Team sprint to an athlete’s sprint ends.

Unlike an athlete who collapses in exhaustion at the end of a sprint, the team needs to keep carrying on from sprint to sprint, with little or no pause in between. For an athlete, this approach would be catastrophic because there would be no chance for recovery between sprints and performance would decay over time, sprint after sprint. We want to avoid this. Pushing hard to reach a short-term goal may at times be justified but is not recommended long term, as it is not sustainable. The key to Agile sprinting is sustainable pace. Pushing people to their limits in every sprint is not sustainable.

Too often I have seen the results of a team that is repeatedly pushed to the limit. It is counterproductive and results in the exact opposite of the desired outcome — the team will burn out, productivity will suffer, and the end result is a demoralized team. There will be a high level of churn as people leave the workplace in search of a better job that has realistic demands.

There has to be a better way of describing the Agile process instead of "the sprint." We have it: "The iteration."
 

The iteration

Synonymous with sprint in Agile terminology, I personally prefer the term iteration. Why? By definition, an iterative process is something that is repetitive and repeatable. It is a cycle that, if set up correctly, can continue indefinitely. The term iteration therefore fits the requirement of being sustainable. The key here is to find a steady pace that the team can maintain. The iteration process is therefore more akin to a long-term endurance marathon than it is to a short sprint. Finding the right speed or velocity is crucial to a team’s success in the long term.

So how does a team find this sweet spot of sustainable pace? One of the most important metrics that a team has is its velocity. The team velocity is a metric that measures the average number of story points that a team can realistically complete each iteration. It is therefore highly recommended that a team excludes any iterations that were not “normal.” By this I mean that the team should not count any iteration where there was a spike in team output or where there was a sudden drop in velocity. For instance, if a substantial number of people on the team were on holidays during a sprint, then any statistics for that iteration should be viewed in isolation compared to normal team velocity. What is needed is a number of repeatable iterations where the team members and team size remain consistent and “normal” conditions prevail — and without pushing productivity boundaries. Once an “average” velocity is discovered by the iterative process, then the team has a good feeling for the amount of effort they can commit to for any given sprint and can plan accordingly. Only then will iteration “sustainability” be achieved and the phrase "the sprint" be viewed as it should be — a poor analogy for what is really an "iteration"!
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3 (2 ratings)

Comments

Phillip Stiby, CSM, 9/26/2016 7:15:04 AM
If your running your sprints like a marathon, then you would get burn out. Your sprints should be more like High intensity interval training (HIIT).

The concept of HIIT is a short burst at full speed, followed by a short break before repeating. So like with Scrum you review, retrospective and planning is your short break to recover.

It seems you are not spending enough time in the your rest period and in fact what your advocating is more eXtreme Programming approach to project delivery and not Scrum.

The ideology of Agile is a sustainable pace and this is what Scrum advocates, if your team are burning out the question is not whats wrong with Scrum but more what wrong with how your implementing Scrum? Is your team self organising, does your team make the commitment or do you have dead lines imposed? Is/can the team make the improvements needed?

Scrum much like so many technologies are great when used in the correct environment with the right people, but sometimes it is not. Question are you or can you use Scrum? If not then do something different, don't try and make some changes to the framework and still call it Scrum, you are just deluding yourself.
Tim Baffa, CSM, 9/26/2016 10:09:34 AM
Agree with Phillip, in that the "rest" between sprints is the Review/Planning/Retrospective period. In fact, I highly encourage my teams to treat the Retrospective as a "breather", and to use it to take a break and reflect on the past sprint and how the team is performing.

Calling it by another name (Sprint/Iteration) may just mask the symptoms instead of addressing them (are teams being pushed to run at full speed?).

One item I would like to address directly though is the use of velocity in the article. Velocity is a reflective metric used as a guideline for projecting future delivery productivity/pace. By NO means should some sprints be left out of a team's velocity calculation simply because they were not ideal.

Perhaps the team was impeded and couldn't finish some stories, or there was a higher amount of vacation on the team, or the team had a "spike" because they completed a few stories that were carried over from the previous sprint. Why would we discount such a result because it was atypical?

Cherry-picking the cream of the crop of past sprints in order to identify an "acceptable" velocity metric to use is a very unwise practice, as it sets false expectations around team productivity, is not a comprehensive backward-looking metric, and introduces waste (selecting the sprints to use for calculations, discussing/determining how the current sprint offer, story readiness, and team capacity measure against this "ideal" velocity metric, etc).

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe