Differences Between Scrum and XP
9 September 2016
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.
Scrum and Extreme Programming (XP) are both Agile approaches to software development and, for that reason, are very much aligned. They share the concepts of iterative development, working software, release and iteration planning, daily meetings, and retrospectives — all elements of an Agile process. The are in fact so well aligned that sometimes it is difficult to distinguish between one team doing Scrum and another doing XP.
There are, however, differences as well, some of them subtle. One particular difference, which I consider the most important, is related to their scope.
Scrum is, in essence, a set of management (or self-management) principles, practices, and processes that people use to work together to complete a project — not just a software project, as we know, despite its initial development for this purpose. Scrum does not actually prescribe any engineering practices.
On the other hand, XP is a dedicated approach to software development. The name actually comes from the fact it takes all common aspects of a software development process and takes them to an extreme (in a positive way). In this context, XP comes with a set of engineering practices that it prescribes, such as test-driven development, refactoring, pair programming, and continuous integration.
All these practices were eventually adopted by teams using Scrum or Kanban, or other software development methods, because they are so powerful and provide so much added value to the developed software. However, they were initially part of XP.
This generates a contradiction: On one hand, XP inherits everything that an Agile process is, including self-organization, self-coordination, and team empowerment. On the other hand, it mandates some engineering practices, which comes in conflict with the previous statement. Although the practices have proven value, it is important that each team discovers that value on their own; this is the only way they will actually produce the expected added value.
Another subtle difference between Scrum and XP is related to the way they handle the product backlog. XP has a rigid approach; items are implemented in a strict priority order. Features are prioritized by the customer (the equivalent of Scrum product owner) and the team is required to work on them in that order.
On the other hand, while a Scrum product owner also prioritizes items, the team actually decides what will be implemented. Of course, following Agile principles, teams will almost always choose to implement the items in the order of their priority. However, a team has the flexibility to choose to implement other items further down the list, for a variety of reasons: Perhaps they are tightly related to a high-priority item already in development. Or maybe they are small enough to complete during the iteration plan while the next item in priority order is too big to fit the current iteration. Or perhaps the team already is working on the section of the code on which the lower priority item will also be implemented, so they decide to make all changes to that section at once.
Which of the two approaches is better can generate a long discussion. The flexibility introduced by Scrum might have a positive effect in the sense that work is done more coherently, developing related items together. Or it might encourage the teams to choose lower-priority items and so affect the whole purpose of the Agile process (to deliver as much added value to the customer as possible, in every iteration).
Although both processes use iterations, there is an important difference between them: Scrum teams typically work in iterations (also called sprints) of two to four weeks, while XP iterations tend toward one to two weeks. This gives more flexibility to XP, because it can accommodate changes into working software more rapidly, while the Scrum team needs to wait — sometimes a month — before taking on a change.
Moreover, Scrum teams are not allowed to accept changes during their sprints. Whatever is planned at the beginning of the sprint is implemented (depending on the velocity), but nothing else is added. XP teams are allowed to substitute items from the iteration plan as long as their development has not yet begun, and the new feature has an equivalent size.
In essence, both approaches closely follow Agile principles. Elements from one method are used in the other without much of a problem. The differences are mentioned not to state which one is "better" but to see where each one fits best, or how to combine them. You can, for example, start with Scrum and adopt XP practices along the way.
Current rating: 2.9 (8 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.