Extreme Programming
Short feedback cycles reinforced by disciplined engineering practices.
Extreme Programming (XP) builds software in short weekly cycles driven by customer-valued stories and reinforced by disciplined engineering practices. Tests are written before code. Changes integrate continuously. Programmers work in pairs. The customer is a first-class participant who selects stories and reviews working software every week. XP is built on the premise that good engineering discipline and frequent feedback make rapid change safe.
What it's for
XP works well for software teams facing changing requirements and demanding quality needs — teams that want tight engineering practices (TDD, continuous integration, pairing) baked into their delivery cadence rather than added on later.
Work item types
| Type | Description |
|---|---|
| Story | Customer-valued behavior to be delivered |
| Defect | Incorrect product behavior |
| Technical task | Engineering enablement work |
| Experiment | A test of a technical or product idea |
Stories are the primary planning unit. Defects, technical tasks, and experiments roll up into stories.
Workflow
The board uses five columns:
| Column | Meaning |
|---|---|
| Stories | Customer stories waiting to be accepted into an iteration |
| Iteration | Stories accepted into the current weekly cycle |
| Developing | Active development work (WIP limit: 5) |
| Tests passing | Work where acceptance tests pass, awaiting integration (WIP limit: 3) |
| Released | Shipped to customers |
Rituals
Skopo calls these Rituals in the sidebar for XP projects.
| Ritual | When | Purpose |
|---|---|---|
| Weekly cycle | Weekly | Customer selects stories and the team plans tested delivery |
| Daily coordination | Daily | Coordinate pairing and integration |
| Acceptance test review | Weekly | Confirm customer tests describe the next deployable behavior |
| Customer review | Weekly | Gather rapid feedback on working software |
| Quarterly cycle | Quarterly | Set release context and themes |
Practices
XP practices can be enabled or disabled per project in Project Settings.
| Practice | What it adds |
|---|---|
| TDD | Drive implementation from automated tests and expected behavior |
| Pair programming | Use two-person programming to spread context and improve quality |
| Continuous integration | Integrate frequently with automated build and test feedback |
| Refactoring | Continuously improve design while preserving behavior |
| Collective ownership | Make the whole team responsible for improving any part of the codebase |
TDD and Continuous integration are recommended by default.
Artifacts
- Stories — customer-valued descriptions of expected behavior, written before implementation.
- Acceptance tests — executable tests that confirm a story is delivered as the customer intended.
- Coding standard — the shared conventions the whole team applies to keep the codebase collectively owned.
Metrics
| Metric | What it measures |
|---|---|
| Build health | Reliability of the automated build across integrations |
| Integration frequency | How often changes are integrated into the shared codebase |
| Escaped defects | Defects discovered by customers after release |