Scrum manages work. It organizes a team’s time into Sprints and leaves coding technique alone. Extreme Programming (XP) goes the other way, with rules for how developers write and test code and how often they merge it.
Which one a team needs depends on what’s actually broken. Planning that drifts points to Scrum, and sloppy code points to XP. If both are broken, the usual answer is to run Scrum with XP practices added.
A lot of top-ranking comparison pages say Scrum forbids any change inside a Sprint. That’s not what the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland says. Scope can be renegotiated with the Product Owner, as long as the Sprint Goal stays intact.
The real split is engineering practice. The Guide leaves it to the team, and XP names it outright.
How Do Scrum and Extreme Programming Differ?
Work management is Scrum’s territory. It arranges a team’s effort into fixed-length Sprints, with its own accountabilities and events plus a few artifacts to track the work. XP covers the other side, with rules for writing and testing code and for how often that code gets integrated.
So they sit at different layers, which is why they combine so easily.
| Attribute | Scrum | XP |
|---|---|---|
| Primary focus | Work management: accountabilities, events, artifacts | Engineering discipline: practices and values for code |
| Iteration length | Sprint of one month or less | Weekly cycle (second edition); sources cite 1 to 3 weeks |
| Change inside an iteration | Scope renegotiated with the Product Owner if the Sprint Goal holds | Unstarted story swapped for one of equal size |
| Roles | Product Owner, Scrum Master, Developers | Customer, programmers, coach |
| Engineering practices | None prescribed; a Definition of Done sets the quality bar | Pair programming, test-first programming, continuous integration, incremental design |
| Values | Commitment, Focus, Openness, Respect, Courage | Communication, Simplicity, Feedback, Courage, Respect |
Both belong to the wider agile approach to building software, and the overlap is large. Both run short iterations that end in working software, and both hold a retrospective so the team can change how it works.
The split comes from the Scrum Guide itself. It calls the framework intentionally incomplete, so engineering technique stays a team decision.
XP fills that gap with named practices. A team following the Scrum framework can adopt them, because the Guide itself says Scrum works as a container for other techniques.
How Scrum Is Structured
One small team takes an ordered list of work and turns it into a usable Increment during a Sprint. Then it inspects the result and adjusts. The Guide calls the whole thing a lightweight framework, and the cycle repeats until the Product Goal is met or abandoned.
Ken Schwaber and Jeff Sutherland developed it in the early 1990s and first presented it together at the OOPSLA conference in 1995. The first teams to try it worked at Individual Inc., Newspage, Fidelity Investments and IDX (now GE Medical), per the Scrum Guide’s own history.
As of October 2026, the November 2020 edition is the version published at scrumguides.org.
Accountabilities and the 2020 terminology change
The Guide puts a typical Scrum Team at 10 or fewer people, with no sub-teams and no hierarchy.
Inside that group, the Product Owner orders the Product Backlog and answers for the value of the product. The Scrum Master establishes Scrum as the Guide defines it and removes impediments. Everyone else is a Developer. Developers build the Increment and plan the Sprint, and they answer for quality through the Definition of Done.
Several comparison pages still say “Development Team.” The 2020 Guide dropped that term in favor of Developers, and it describes the whole team as self-managing rather than self-organizing.
Events and artifacts
Everything happens inside the Sprint, a fixed-length event of one month or less.
Around it sit the other Scrum events. The timeboxes below assume a one-month Sprint, and shorter Sprints get shorter events.
- Sprint Planning: 8 hours maximum
- Daily Scrum: 15 minutes
- Sprint Review: 4 hours maximum
- Sprint Retrospective: 3 hours maximum
Work gets tracked through Scrum artifacts, and each one carries a commitment. The Product Backlog is tied to the Product Goal and the Sprint Backlog to the Sprint Goal. The Increment gets the Definition of Done.
The Definition of Done is where Scrum states a quality bar. It says nothing about how to reach it.
Partial Scrum is not Scrum. The Guide calls the framework immutable and says that leaving out elements covers up problems.
The five Scrum values
Commitment, Focus, Openness, Respect and Courage shape how the team behaves in every event.
The Guide ties them to the three empirical pillars of transparency, inspection and adaptation. They describe conduct, not technique, and nothing in them tells a developer how to write a test.
Extreme Programming Practices, Roles and Values
Kent Beck created Extreme Programming (XP), an agile software development approach, by taking familiar engineering practices, testing and code review among them, and pushing them to extreme levels. Frequent integration got the same treatment.
It grew out of Chrysler’s C3 payroll project. Beck became project leader in 1996 and brought in Ron Jeffries as coach, and the restarted project pulled together the practices that Beck later formalized as extreme programming.
C3 went live in 1997 and was cancelled in February 2000 after Chrysler’s merger with Daimler-Benz. Martin Fowler, who consulted on the project, notes that the cancellation proves XP is no guarantee of success.
Core practices
Beck’s first edition (1999) listed 12 practices. The second edition (2004, written with Cynthia Andres) reworked them into 13 primary and 11 corollary practices.
Grouped by purpose, the primary practices sort out like this.
- Test-first programming, the ten-minute build, continuous integration and incremental design all go toward code quality
- Pair programming, sit together, whole team and informative workspace cover collaboration
- Stories, the weekly cycle, the quarterly cycle and slack handle planning
- Energized work stands alone, and it means a pace the team can hold
Test-first programming is what most developers call test-driven development. Write a failing test, then write the code that passes it.
The corollary practices lean on the primary ones. Daily deployment, for example, assumes the low defect rate that test-first programming and pairing produce once continuous integration is in place.
Who is on an XP team
XP has a customer who sits with the team and sets priorities. Programmers write the code and the tests, usually in pairs, and a coach helps everyone turn the practices into habits.
The first edition also named a tester and a tracker. The second edition describes a Whole Team instead.
XP values: four or five
Sources disagree on the count, and the edition explains why.
The first edition named four values: communication, simplicity, feedback and courage. The second edition added respect, which an overview of the book on xp123.com flags as the new value, and the Agile Alliance glossary now lists all five.
Beck defines courage as “effective action in the face of fear,” per the same glossary.
Respect and courage appear on both lists. Scrum adds commitment, focus and openness. XP’s extras are communication, simplicity and feedback.
Scrum’s extras are about conduct around the work. XP’s map straight onto practices. The Agile Alliance ties sitting together to communication, for one, and short feedback loops to simple design.
How Scrum Accountabilities Map to XP Roles
The Product Owner lines up with the XP customer, and Scrum’s Developers with XP’s programmers. The Scrum Master only loosely matches the coach. Of the pairs, Product Owner and customer is the closest fit, and Scrum Master and coach the weakest.
A Product Owner is one person, not a committee, who orders the Product Backlog and answers for product value. XP puts the customer inside the team, and Beck’s second edition names Sit Together, Whole Team and Real Customer Involvement as practices.
The Scrum Master serves the team, the Product Owner and the wider organization. The XP coach has a narrower job, and Jeffries, coaching C3, worked to build the practices into habits.
The Guide uses Developers for anyone who builds any part of the Increment, so testers and designers count. XP’s programmers write code and tests, usually in pairs.
The mapping gets shaky at the edges. The Guide asks the Scrum Master to coach self-management and cross-functionality, not technical practice, and the XP coach teaches practices, not the Scrum events.
In a combined setup, keep Scrum’s three accountabilities as written and make technical coaching an explicit duty of the Developers. The Guide assigns it to none of the three.
Sprint Length and Mid-Iteration Change Compared
XP iterations run shorter than Sprints in most sources, and both methods let scope move mid-iteration, just under different conditions. Scrum protects the Sprint Goal. XP protects work that has already started.
The sources give a few different numbers for length.
- Mountain Goat Software puts XP iterations at one or two weeks.
- A Scrum.org community answer says one to three weeks.
- Cprime says three weeks was the length when Beck first created the method.
- The 2020 Scrum Guide sizes Sprint Backlog work items at one day or less.
The spread has a simple cause. XP names a weekly cycle but sets no hard cap, and the Scrum Guide sets a ceiling, not a floor.
A one-week Sprint is valid Scrum. The Guide says shorter Sprints give the team more learning cycles and limit the cost of a wrong call.
Comparison pages tend to say Scrum allows no change inside a Sprint. Mountain Goat Software’s comparison puts it that way, and so does CIOReview. That claim keeps getting repeated, and it’s wrong.
The Guide is looser. During a Sprint, no change may endanger the Sprint Goal and quality does not decrease. Beyond those two limits, the Product Backlog is refined as needed, and scope can be clarified and renegotiated with the Product Owner as the team learns more.
Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. The disagreement sits between the Guide’s text and its summaries, not between two readings of the Guide.
XP draws a different line. An unstarted story can be swapped for a new one of equal size (Mountain Goat Software), and anything already in progress stays put.
Put simply, Scrum holds the goal and lets scope move underneath it, while in XP the stories already started are the ones that can’t move.
In practice the gap is narrow. Both allow change before work begins, and both refuse to disrupt work the team has committed to.
Which Should a Team Choose, Scrum or XP?
If the trouble is planning and inspection, pick Scrum. If it’s the code itself, pick XP. A team with both problems should run both.
Start with whether the work is software at all. If it isn’t, Scrum is the only candidate, because the Scrum Guide describes use well beyond software and XP’s practices assume a code base.
Next, look at engineering habits. A team that already has strong ones can get by on Scrum’s lighter rule set.
After that comes the customer question. XP’s rules assume the customer is always available, so can a customer representative answer story questions the same day? And last, can the team sit together or share a working session? XP’s pairing and sit-together practices lean on it.
The starting point is where the experts disagree.
Mike Cohn of Mountain Goat Software advises starting with Scrum and letting the team invent its own version of XP. His reason is that practices a team discovers earn more commitment than practices handed down.
James Shore (2008) recommends the opposite and adopting the full XP set from day one. In his experience Scrum teams win early and then struggle, while XP teams take more pain at the start and reach a high-performing state within the first year.
Both say that forcing practices on a team fails. The dispute is about the starting point, not the destination. My own lean is toward Cohn’s route for most teams, mainly because forced practices go sour fast.
| Option | Pros | Cons |
|---|---|---|
| Scrum | Fits complex work outside software; small rule set; one short official definition | No technical practices, so code quality rests on the team’s own habits (Fowler, 2009); early wins can hide a growing code problem |
| XP | Practices are named, so nothing to invent; short feedback loops from test-first programming and continuous integration; customer close to the team | Hard to adopt because the practices arrive together; needs an available customer; software only |
When Scrum and XP Break Down
Scrum tends to break when nobody owns engineering quality. XP runs into trouble when its practices are mandated, or when they get applied somewhere they don’t pay off.
Martin Fowler named the Scrum pattern Flaccid Scrum in January 2009. Teams adopt the Scrum events while the code base degrades, and progress slows under heavy technical debt.
Fowler does not blame the framework. Scrum leaders insist on good technical practices, he says, and XP’s practices are a sound place to start.
The Guide flags more risks itself.
- A Sprint horizon that runs too long can invalidate the Sprint Goal and raise complexity and risk
- A Product Owner whose decisions the organization does not respect is another, since the Guide says the entire organization must respect those decisions for Product Owners to succeed
Pair programming as a blanket rule is the XP-side trap. A 2009 meta-analysis by Hannay and colleagues in Information and Software Technology found a small positive effect on quality and a medium positive effect on duration, along with a medium negative effect on effort.
The detail matters more than the averages. Pairs finished simple tasks faster but with lower quality, and they produced better solutions to complex tasks at considerably greater effort.
The same paper reports significant variance between studies and signs of publication bias. Pairing on complex work buys quality, but the effort cost is high. On simple tasks it buys speed and costs some quality.
Practices handed down as rules fail for a different reason. Cohn and Shore disagree on the starting point, yet both say teams commit to practices they adopt themselves.
XP also doesn’t apply outside software. Test-first programming, continuous integration and refactoring assume a code base, so they don’t transfer to other kinds of work. Scrum does transfer, which is why the Guide describes adoption in domains beyond software.
How to Add XP Practices to a Scrum Team
Run Scrum as written, then add XP practices one at a time. Each one should come from a problem the team surfaced and get written into the Definition of Done or the Sprint Backlog. Cprime describes the result as Scrum supplying the framework and XP’s technical practices supplying feedback loops that act as safety nets for change.
The Sprint Retrospective is where the choice gets made. The Guide has the team inspect its processes and tools, along with its Definition of Done, and the most useful improvements can enter the next Sprint Backlog.
- Run Scrum as written for the first few Sprints, with a Definition of Done the whole team can state.
- In the first Retrospectives, list where time went, such as rework, painful merges, repeated defects or knowledge held by one person.
- Pick the one XP practice that targets the top item.
- Write it into the Definition of Done or the Sprint Backlog so it shows up as visible work.
- Run it for a Sprint or two, then judge it in the next Retrospective and keep, adjust or drop it. The XP rules on extremeprogramming.org say as much. Fix XP when it breaks.
- Add the next practice only after the first one holds.
Painful merges are a continuous integration problem, and bugs that keep coming back usually mean the team needs test-first programming. When knowledge sits with one developer, pair programming helps, though it’s best kept for complex work given the effort trade-off.
Some of the vocabulary carries over. A Scrum.org community answer notes that XP stories are a format for Product Backlog items and that XP iteration planning matches Sprint Planning. XP release planning has no Scrum event, so a team that wants it keeps it as a planning habit above the Sprint.
Henrik Kniberg’s account of a Swedish company with about 40 people covers a year of this kind of experimentation. The team layered continuous build, pair programming and test-driven development onto Scrum (InfoQ, 2007).
There’s a faster route. Shore advises new teams to adopt the whole XP set at once. Take it only when the team wants it, because forced adoption fails in his own account too.
Scrum vs Extreme Programming FAQ
Which is more widely used, Scrum or XP?
Scrum, by a wide margin. Digital.ai’s 15th State of Agile report (2021) found 66% of respondents following Scrum most closely, with another 6% following a Scrum/XP blend.
Does XP work for remote teams?
Partly. Test-first programming and continuous integration live in the code, so location does not affect them.
Sit Together does depend on location, because the Agile Alliance describes it as a shared space without barriers. Remote teams have to replace it, and pair programming then runs through screen sharing.
Which tools support Scrum and XP?
For Scrum, backlog and board software such as Jira does most of the work, holding the Product Backlog and the Sprint Backlog.
XP leans on test frameworks instead. Kent Beck wrote SUnit, the ancestor of the xUnit family, and later wrote JUnit for Java with Erich Gamma.
Is Scrum a framework or a methodology?
A framework. The Scrum Guide defines Scrum as a lightweight framework and calls it purposefully incomplete, so technique comes from the team.
XP sits closer to a methodology, since Beck’s book describes a discipline. The Agile Alliance glossary still labels it a framework, so sources use both words.
How different is introducing XP from introducing Scrum?
A Scrum.org community answer sees no significant difference in how either one is introduced. XP’s description runs longer than the Scrum Guide only because it prescribes more practices.
The difference shows up after the introduction. James Shore (2008) calls XP the harder of the two to adopt, though it pays back within the first year.
How to Judge a Scrum and XP Combination
A Scrum and XP combination works when every added practice sits in the Definition of Done and the team can name the problem it removed. A practice with no named problem gets dropped first.
Drops should follow cost and evidence. Pair programming on routine tasks goes first, then any practice that was mandated rather than chosen. Test-first programming and continuous integration go last.
Read together, the pairing meta-analysis and the Cohn and Shore adoption accounts single out mandated pairing as the weakest-justified practice, a conclusion neither source states.
Test-first programming and continuous integration stay longest because they keep the Definition of Done checkable every day. Dropping any practice trades a feedback loop for person-hours.
A Scrum Guide edition that prescribes technical practices would reverse this order, and none had replaced the 2020 text when this was verified in October 2026.
- How to Run a React App in VS Code Step by Step - October 23, 2026
- Transactional or marketing email: which messages your app should send itself - October 23, 2026
- How Software Teams Write SOPs for Releases and Deployments - October 22, 2026
