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.