Sprint, Iteration or Marathon?
A short blog on terminology...
I have always found it hard to differentiate an Iteration from a Sprint, so much so that I commonly say they mean the same thing. They are synonymous. I use the two interchangeably. The difference is historical, the term “Iteration” originated in XP and “Sprint” in Scrum.
To me they both mean: a short period of time in which work is done.
Occasionally people have attempted to differentiate the two terms but I’ve never been convinced.
“Sprint means a fixed period of time during which the team commit and work towards a fixed goal which does not change. Iteration means a fixed period during which the team undertakes some work - no commitment, no fix work.”
Most of the time the difference probably does matter but I like Rachel’s differentiation. It ties Sprint quite closely to Hard Core Scrum.
I really should try to stick to Iteration.
Actually, I think the real Sprints occurs when:
- A team starts a new piece or work and they have no idea what they are up against. They are sprinting to maintenance mode. Risk is highest when sprinting, until the team has their walking skeleton - a thin slice of functionality that does something tiny
- Or when a team are first trying a new way of working (probably Agile-like). They have a short period of time where the rest of the organization doesn’t know what they are doing, or if they do will extend good will to let the team try. A honeymoon, if you like. At the end of that time the team needs to be able to show something better. Otherwise, the good will is gone and with nothing to show for it people feel let down. Again, risk is high.
Real software isn’t about sprinting; real software development is a Marathon. You need to pace yourself. The danger with constantly sprinting is that you burn out.
Real software development is a marathon run in laps. We call the laps iterations.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)