Sprint v Iteration

Chris Oldwood asked me about the difference (as I see it) between the Scrum concept of Sprint and Iteration in XP. Although the terms “Sprint” and “Iteration” are often bandied around as synonyms in Agile world with the basic meaning of a time boxed planning cycle used by a software development team, these terms started out with quite different meanings.

Here’s a quick brain dump of my thoughts on key differences.

The purpose of a Sprint in Scrum is to deliver a product increment - a coherent release not a hotchpotch of unrelated features.

When I learned about old-school Scrum (back in 2002 before Scrum Alliance existed), a Product Owner would work with the team to agree an achievable Sprint goal that the team felt they could commit to delivering in a month. The focus of the team was a achieving a goal defined around what the next product increment would be. The Sprint Backlog was simply a list of tasks defined by the team that would help them achieve that goal. Tasks could be added or removed during the Sprint but the goal remained the same.

Around this time, there was no mention in Scrum about user stories and complexity points, these techniques hadn’t been imported from XP yet. So key concepts in Scrum - a goal for the product, a commitment from the team and a release of a product increment.

Agreeing direction and empowering the team to achieve it removes interruptions during the sprint and allows the team to focus attention on the product under development. Although once a product is released there’s likely to be a stream of defects and support requests to be handled by the team which may slow them down later if they don’t pay attention to quality.

XP is a an approach for small teams developing software in the face of vague or rapidly changing requirements.

Back in the day, a team of developers sat down with their on-site customer to play the Planning Game. User stories were jotted on index cards are laid out on the table to be prioritised by value and risk. To quote Kent Beck "We make the plan quickly so there will be little inertia changing it"

XP does not need and end of iteration ceremony to demonstrate or review an increment because software is released as soon as it is ready. Each story has acceptance tests and is releasable independently of the other stories -- remember Bill Wake’s INVEST.

Teams applying XP are encouraged to “embrace change” to listen to user feedback. There is no sense that an XP iteration is frozen or locked down. It’s possible to make small adjustments to stories as they’re worked on and also to swap user stories in and out of the iteration, if we discover something more valuable to work on. XP teams use Yesterday’s Weather (planning poker and velocity) to help them avoid taking on too much work not to make a commitment.

The funny thing is that neither of these versions of Scrum or XP are commonly practiced nowadays. Perhaps that’s down to the proliferation of Agile training lead by people who haven’t implemented these older approaches and planning tools that place more emphasis on velocity tracking for project management purposes. I see the #noestimates movement as a reaction to the blend of Scrum and XP that bloats the ceremony around planning beyond original ideas.

Comments

[Bigpinots]

And may explain the growing interest in Kanban?

[Bigpinots]

I remember the original "theme-based" approach, but it was a bit idealistic and not as embracing of change as iterations. Maybe that's why iterations were adopted by much of the Scrum community? Do you think Scrum adapted to take bits of XP that were more adaptable than Scrum's native approach, or do you think it was a misunderstanding/bastardisation? I'd be interested to hear your thoughts on that.

[Growingtruffles.wordpress.com]

Whoa! That bit of history about scrum not having stories back in the day is hugely illuminating! Our company has been weak about using sprint goals, strong on stories. As such, sprint goals always seemed to me a weird add-on. I like the idea that they can provide a clear beacon that doesn't change, even if the stories have to get torn up and rethought mid-sprint, but it seemed that was a rare case. And because sprint goals got developed at sprint planning to bundle together stories that had been groomed previously, attempts to get the team to define them usually fell flat. On the occasions where they did it, referring back to the goal (rather than just focusing on the set of stories), felt forced.

Understanding that stories were a later addition clears that up. And it makes me wonder if we should be relying on stories less and goals more. I have to think about this some more and figure out how to use sprint goals correctly.

Thanks for the post!