XP + Scrum

Scrum provides organizational structure. XP provides engineering practices. Together, they address different gaps:

Scrum gives you:

• Defined roles (Product Owner, Scrum Master, Developers)
• Rhythm (Sprints, Sprint events)
• Artifacts (Product Backlog, Sprint Backlog, Increment)
• Accountability structures

XP gives you:

• How to write code well (TDD, refactoring, simple design)
• How to collaborate on code (pair programming, collective ownership)
• How to deliver reliably (CI, small releases)
• Team health practices (sustainable pace, coding standards)

Scrum is silent on how developers should actually code. XP fills that gap.

Most successful "Scrum teams" are really doing Scrum + XP engineering practices, whether they call it that or not.

Sprints = Iterations Scrum's sprint is XP's iteration. Timeboxed, focused, delivering working software.

Product Backlog = Release Plan XP's release planning creates the work; Scrum's Product Backlog organizes it.

Sprint Planning = Iteration Planning Same activity: decide what to build this iteration, break it into tasks.

Daily Scrum = Daily Standup Same intent: synchronize the team, surface blockers.

Sprint Retrospective = Retrospective XP doesn't prescribe retrospectives as rigidly, but the practice is the same.

User Stories Work in both approaches. Scrum doesn't prescribe the format; XP's story format works well.

Sprint Review = Demo XP's iteration demos are essentially Sprint Reviews.

The terminology differs; the practices align.

Scrum teams that adopt XP practices typically see:

Better code quality: TDD catches bugs early. Refactoring keeps design clean. Collective ownership spreads knowledge.

More predictable velocity: When quality is high, velocity stabilizes. No surprise slowdowns from bug fixing.

Sustainable pace: XP explicitly names and protects this. Scrum can become a "sprint" in the wrong sense—always pushing.

Improved collaboration: Pair programming builds relationships. Collective ownership breaks down silos.

Continuous improvement: XP's principle of improvement plus Scrum's retrospectives create a powerful combination.

Common pattern: Teams start with Scrum because it's organizational. They add XP practices as they mature. The combination is more powerful than either alone.

While XP and Scrum work well together, some tensions exist:

Scrum Master vs. XP's Self-Organization XP assumes the team self-organizes deeply. Scrum adds a role (Scrum Master) to facilitate. These can coexist, but if the Scrum Master becomes a command structure, XP's self-organization suffers.

Sprint Commitment vs. XP's Flexibility Scrum emphasizes sprint commitment. XP emphasizes responding to change. If commitment becomes rigid, XP's adaptability is lost.

Definition of Done vs. Continuous Quality Scrum's "Definition of Done" can become a checkbox. XP's quality practices are continuous. Ensure DoD reflects XP quality, not just "tests pass."

Velocity as Metric Scrum often tracks velocity. XP warns against velocity as a target (it gets gamed). Use velocity for planning, not performance measurement.

These tensions are manageable. The key is keeping XP's principles alive while using Scrum's structure.

To combine Scrum and XP effectively:

Use Scrum's structure:

• Sprints for rhythm
• Product Owner for priorities
• Scrum Master for facilitation
• Sprint events for cadence

Add XP's practices:

• TDD for all production code
• Pair programming (at least for complex work)
• Collective ownership (no code silos)
• Continuous integration (multiple times daily)
• Refactoring (as part of every story)
• Sustainable pace (no overtime)

Keep XP's principles:

• Quality is non-negotiable
• Start where you are and improve
• Embrace change
• Feedback at all scales

Many teams discover this combination naturally. They start with Scrum, realize they need engineering practices, and add XP. The result is often called "agile done well."