Get certified - Transform your world of work today

Close

Differences Between Scrum and XP

9 September 2016

Adrian Sita
Brain Concert


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.
 

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: 2.9 (8 ratings)

Comments

Vinod Kumar Marothy, CSP,CSM,CSPO, 9/28/2016 8:20:45 AM
Very basics. Nice article.
Piotr Przygoda, CSPO, 12/7/2016 4:54:57 PM
I do not agree with a couple of sentences, although I do understand this is just Adrian's opinion.
Just to give you an example:
"Scrum teams are not allowed to accept changes during their sprints" - I totally disagree. It sounds like a waterfall approach while Scrum is about collaboration. If Dev Team raises an issue saying they need to apply an adjustment/change, it's a discussion with PO then. On the other hand, if PO sees the sprint goal obsolete we should react as well. Maybe it's wording but quite important to me.

Anyway - comparing Scrum and XP - for me it's more about where we set the focus. Ignoring the technical differences between the methods/frameworks, in Scrum it's more about on-going improvements and maximizing the value delivered. In XP the highest value (as seen by the client) takes priority.

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