Better Together — XP and Scrum

It has long been a source of amusement (and frustration) to me how common it is for many in the industry to use terms like “Scrum but …” in a pejorative sense, implying that teams should only be following the small set of practices that are part of Scrum. The reality is that for any Agile team to be able to repeatedly deliver working software over any significant length of time, Scrum by itself is not enough. Whether they realize it or not, the vast majority of teams that call themselves Scrum teams are operating as a Scrum-XP hybrid, where they employ at least a subset of the technical practices that originated with XP.

Let me go on the record and say that teams that are only following the Scrum practices are unlikely to be successful over the long term, because at least a subset of the XP technical practices are a must for ongoing success as an Agile delivery team.

What’s the difference between Scrum and XP?

I have observed that there are not enough people who understand what Scrum does and does not include, so let’s start there.

What Scrum is — a set of management practices

Scrum is the application of empirical process control, which is a fancy way of saying that we should be making decisions based on experience, not based on some hypothetical set of assumptions that are not grounded in reality.

Simply stated, Scrum consists of a small set of management practices that are intended to help teams collaborate effectively and deliver work in an iterative fashion (let me emphasize once again — there are zero technical practices in Scrum).

To briefly summarize the contents of the Scrum Guide:

  • There is a Scrum Team, which is composed of the Development Team, the Product Owner, and the Scrum Master (historically these have been referred to as the Scrum Roles). Ideally a Scrum Team consists of seven people, plus or minus two (not including the PO and SM).
  • There are Scrum Events, which consist of Sprint Planning, the Daily Scrum (aka Daily Standup, in XP), Sprint Review, and Sprint Retrospective. All of the Scrum Events happen inside of a Sprint, which is a time-box of less than one month. Note that Backlog Refinement, aka Backlog Grooming, although highly encouraged by Agile practitioners, is not one of the Scrum Events (Backlog Refinement has been referred to by Mike Cohn and others as a Generally Accepted Scrum Practice, or GASP).
  • There are Scrum Artifacts, which consist of the Product Backlog, the Sprint Backlog, and the Increment, where the Increment is the “sum of all of the Product Backlog items completed during the Sprint.”
  • There is a Definition of Done, where any Scrum Team has a shared understanding of what “done” means for any Product Backlog item. Note that in contrast to Acceptance Criteria, the Definition of Done is globally applied, while Acceptance Criteria are specific to individual Product Backlog items.

What Scrum is not

Contrary to popular belief, none of the following things are part of Scrum:

  • User stories. The vast majority of the work items in any given Scrum team’s Product Backlog or Sprint Backlog are written as user stories (often in the format “As a <persona/role>, I want <goal>, so that <desired outcome>”), but Scrum does not mandate any particular construct or format. Note that user stories are part of XP.
  • Estimation. Even though the vast majority of Scrum teams do perform estimation at some level, the practice of estimation is not part of Scrum.
  • Velocity. Velocity is not part of Scrum either; the notion of project velocity is part of XP.
  • Technical practices. As noted above, there is no notion of technical practices (CI, CD, pair programming, TDD, etc.) in Scrum. The vast majority of the technical practices that teams typically follow originated with XP.

What is Extreme Programming?

It has been more than two decades since the first Extreme Programming (XP) team was formed, where they worked on a project called Chrysler Comprehensive Compensation (C3). The methods that team employed originated to a large extent in the 1980s, when Kent Beck and many others were experimenting with better ways to develop software, i.e., an alternative to the “waterfall” approach that had become dominant by that time.

Making work visual has always been an important way of informing how Agile teams work. Therefore, as an introduction to XP, I recommend that anyone wanting to learn more would be well served by starting with these diagrams:

Note: For a visual that combines many of the elements from the diagrams above on one page, see Bill Wake’s Extreme Programming Overview.

Additional Reading about XP

If the visuals above intrigue you enough to want to read more about XP, see the following sources of information, which are listed more or less in order of shortest to read > longest to read:

Additional References

All references in this section are from Don Wells’ XP website, unless otherwise noted.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.