Extreme Programming Core Practices

XP's twelve core practices are usually drawn as a set of concentric circles rather than a flat list, because that's the point: they reinforce each other. Practices like Test-Driven Development, Refactoring, Pair Programming, Continuous Integration, and Coding Standards were already covered in earlier chapters as proactive quality practices — this chapter completes the picture with the remaining XP-specific practices: Planning Game, Small Releases, Customer Tests, Simple Design, Collective Code Ownership, Sustainable Pace, Metaphor, and Slack.

Planning Game — the practice that steers the whole project toward customer-valued direction. It's a meeting that occurs once per iteration, divided into release planning and iteration planning, and it runs in three phases. Exploration: gather requirements, write stories, estimate the work, and split stories that are too large. Commitment: find the impact on the project's constraints — cost, benefits, schedule — sort stories by value and risk, and determine scope based on the team's actual velocity rather than wishful thinking. Steering: determine whatever changes are needed to keep the project heading in the right direction, and adjust the plan accordingly. Both the team and the customer are part of release planning; iteration planning covers the specific activities and tasks developers and testers will carry out during that iteration.

Small Releases — frequent, small, valuable releases rather than one large release at the end. This helps both the customer and the team build real confidence in the project as it progresses, lets the customer share suggestions grounded in actual experience with the product rather than speculation, keeps feedback frequent enough to catch the team drifting off course early, and surfaces defects while they're still cheap to fix.

Customer Tests — the customer tests the system directly to make sure expectations and what's actually delivered are fully aligned. The customer writes functional tests and runs them against the system, and accepts or rejects each delivery based on the test results — not on a subjective impression formed after the fact.

Simple Design — the same idea that appears under XP's Simplicity value, applied as a concrete practice: the team finds the simplest way to implement a solution and builds exactly that, delivers only what's needed and nothing extra, and continuously works to eliminate waste, on the understanding that the simplest design that could possibly work is also the most efficient one, and that simplicity itself reduces the surface area for defects.

Collective Code Ownership — everyone on the team is responsible for all the code, and anyone can change any part of it. Whoever finds a problem fixes it as soon as possible rather than filing it and waiting for the "owner" of that module. This reduces the number of issues left to linger in the code, enhances overall quality, increases the team's respect for each other's work, and leads to a shared understanding and visibility of the codebase — nobody is the single point of failure for any one part of the system.

Sustainable Pace — captured in the line "development is a marathon, not a sprint." The agile process promotes sustainable development, where sponsors, developers, and users maintain a constant pace indefinitely, built around something close to a 40-hour week. Stories pulled into an iteration should match the team's actual velocity, and overtime — and the burnout it eventually causes — is deliberately avoided in favor of a healthy, happy, motivated, and genuinely productive work environment. When sustainable pace isn't maintained, the pattern is predictable: a productivity boost shows up only in the first week of overtime, then declines rapidly as mistakes creep in and quality drops. Sustainable pace isn't about working less for its own sake — it's about spending the team's energy wisely on the right priorities, because people who are enjoying their work want to keep doing it, and a project is a long distance to cover without fatigue or collapsing morale getting in the way.

Metaphor — a comparison between two seemingly unrelated subjects, used in XP to give the whole team — technical and non-technical stakeholders alike — one shared, simple way to talk about the system's architecture. Describing a payment system as an "assembly line" or a routing component as a "post office" gives everyone, regardless of technical depth, a common mental model to reason about the system with, instead of forcing non-technical stakeholders to follow a purely technical description.

Slack — adds a small amount of extra capacity into every iteration. XP teams deliberately include a few small, minor user stories — nice-to-have improvements, optimization work, cleanup items — that can be dropped without damaging the iteration if the schedule starts to slip. Slack is what keeps a schedule hit from turning into a crisis: there's already something low-stakes built in that can absorb the pressure.

Study focus: when a question describes a practice that gives a team a small, droppable buffer against schedule slippage, that's Slack specifically — not Small Releases (which is about release frequency) and not Sustainable Pace (which is about avoiding burnout over the long run).