eXtreme Programming

eXtreme Programming — usually just XP — is the most demanding member of the agile family. East Agile Tracker is built for XP first; everything else falls out of it.

This page covers what XP is, why it works, and how to practice it with the tracker as your planning surface.

What XP is

XP was created by Kent Beck in the late 1990s. The first book — Extreme Programming Explained: Embrace Change — was published in 1999. It started, like many things, with a frustrated team trying to ship a payroll system at Chrysler.

XP’s bet is that the right way to handle uncertainty in software is to do the things that work, and do them more often. Test? Test all the time. Integrate? Integrate hourly. Talk? Talk constantly. Plan? Plan every iteration, and re-plan as you learn.

“XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.” — Kent Beck

The five values

XP names five values that everything else hangs off of:

Communication — The team talks. Daily. About the work, the design, the obstacles. Face-to-face when possible. Silos are the enemy.
Simplicity — Do the simplest thing that could possibly work. You can add complexity later if you actually need it. You probably won’t.
Feedback — From the code (tests), from the team (pair programming, reviews), from the user (frequent releases). Get it fast.
Courage — Tell the truth about progress, estimates, and design. Throw away code that doesn’t work. Refactor what’s holding you back.
Respect — Everyone on the team — and now, every agent on the team — contributes value. Treat each other accordingly.

The practices

XP is famous for its twelve original practices, organized in four areas:

Planning

Planning Game — The team and the customer plan together: what’s coming next, in what order, how big is each piece.
Small Releases — Ship often. Days, not months. Get feedback on something concrete.
User Stories — Requirements are conversations, captured as short stories from the user’s point of view. “As a user, I want X, so that Y.”

Designing

Simple Design — The simplest design that passes the tests and expresses every needed concept. No more.
Refactoring — Improve the design of code that’s already working. Constantly.
System Metaphor — A shared story of how the system works, used to make design decisions consistent.

Coding

Pair Programming — Two developers, one keyboard. One drives, one navigates. Switch often.
Collective Code Ownership — Anyone can improve any code. No fiefdoms.
Continuous Integration — Integrate and test code many times a day. Catch breakages immediately.
Coding Standards — Agreed-on style so the code reads as if one person wrote it.

Testing

Test-Driven Development (TDD) — Write the failing test first, then the code that makes it pass.
Acceptance Tests — The customer defines, in code or executable form, what “done” means for each story.

Why XP works

XP is uncomfortable. Pair programming forces you to think out loud. TDD forces you to know what success looks like before you write the code. Continuous integration kills your favorite long-lived branches. Small releases mean you can’t hide behind a six-month roadmap.

It works because all of these things shorten feedback loops. The faster you find out you were wrong, the cheaper the correction. XP is, fundamentally, about making the feedback loop as tight as it can be.

It is also about courage and respect. You can only do XP on a team that trusts each other enough to be wrong out loud.

The disciplined story model

East Agile Tracker encodes a specific theory of planning. Treat this section as the operating manual for why the data model looks the way it does — and as the field guide for what to do (and not do) in practice.

Why the four story types matter

Everything is a story, but there are four kinds, and the distinction is the whole point:

Features carry points and are the only thing that “counts” toward velocity. This forces you to slice work into user-observable value.
Bugs are unpointed (zero). Defects don’t earn credit, which makes the cost of rework visible rather than rewarded.
Chores are also unpointed — necessary work with no direct user value (infra, refactors, setup). Keeping them at zero pressures the team to bundle them into features wherever possible so the value framing stays honest.
Releases are zero-point markers used to anchor milestones and let the tool project a date.

The behavioural effect is what matters: when bugs and chores don’t score, a team naturally pushes to express work as user-oriented functionality, and it becomes acutely aware of defect cost. That’s a planning discipline encoded in the data model.

The single ordered backlog

Three zones, one rule.

The Icebox is the unprioritized idea pool.
The Backlog is a strictly ordered, single-priority list — no ties, no “P1/P1/P1.”
The Current zone holds the active iteration(s).

The product owner owns the order top-to-bottom, and the invariant is that the top of the backlog is always the most important and best-specified, with clarity legitimately decreasing as you go down. A story near the top with vague acceptance criteria is a planning bug. The Icebox is allowed to be a graveyard; the Backlog is not.

Velocity-driven automatic planning

This is the part most teams reimplement badly elsewhere. Tracker-style planning computes a rolling average velocity from recently accepted points and automatically pulls that many points of stories into the next iteration — you don’t manually “commit” to a sprint, the empirical data does it for you. Two consequences worth preserving:

You estimate features only, using relative points (Fibonacci 1/2/3/5/8 or our tighter 0/1/2/3), not hours. Estimation is a sizing conversation, not a promise.
You don’t game velocity. Inflating points to “look fast,” or pointing chores, breaks the projection that makes the whole system honest. Velocity is a measurement instrument, and you don’t tamper with your own instrument.

The payoff is that release date projection becomes a calculation rather than a negotiation, and the conversation with stakeholders shifts from “can you commit to X by Friday” to “at current velocity, this release lands around date Y — here’s the scope/date trade-off.”

The story lifecycle and the acceptance loop

The state machine is Start → Finish → Deliver → Accept / Reject. The critical state is Deliver: an engineer marks a story delivered, but it is not done until the product owner explicitly accepts it against its acceptance criteria — or rejects it, kicking it back. This bakes a customer-feedback loop into every single story rather than deferring acceptance to a sprint-end demo.

Acceptance criteria belong on the story before it’s started, ideally in Given/When/Then form so they map directly onto acceptance tests. INVEST is the sanity check on whether a story is well-formed:

Independent — can be released without other stories.
Negotiable — captures intent, not a frozen spec.
Valuable — to a user or stakeholder.
Estimable — the team can size it.
Small — fits comfortably in an iteration.
Testable — has acceptance criteria that can be exercised.

Cadence

The planning ceremonies are light and regular:

A weekly Iteration Planning Meeting to point new stories and pin down acceptance criteria at the top of the backlog.
A short daily standup focused on flow and blockers.
A retrospective per iteration to adjust the process.

Iterations are usually one or two weeks — short enough that a bad estimate is cheap to discover.

The engineering practices that make planning work

Tracker-style planning is the visible half of XP; it collapses without the engineering half.

Test-first / TDD and a real acceptance-test suite are what let “delivered” mean something.
Continuous integration and small, frequent releases keep cycle time short so velocity is stable rather than lumpy.
Pair programming (or strong review) keeps work-in-progress low — finish before you start — which is the single biggest lever on cycle time.
An available product owner is what keeps the accept/reject loop from stalling.

Anti-patterns to watch

The recurring failures:

Treating the Backlog as a parking lot instead of a true priority order.
Estimating bugs and chores to make velocity look better.
Carrying huge stories that can’t finish in an iteration. Split until each is independently deliverable.
Letting stories pile up in Delivered because no one is accepting.

Any of these quietly converts an empirical system back into wishful planning. The tracker can’t stop you from doing them; it can only make them visible. Look at your Delivered column at the end of every iteration — if it’s growing, that’s your signal.

XP with East Agile Tracker

The tracker is the planning surface XP teams have been wanting since the Pivotal Tracker days. Every concept maps directly:

User Stories → Stories

XP user stories are East Agile Tracker stories. Write them in the Feature type. Use the description for the conversation; use comments for ongoing discussion. The acceptance criteria belong in the description.

Planning Game → The board

The Planning Game in XP is a conversation between business and team about priority and size. In East Agile Tracker:

The product person writes stories in the Backlog and orders them by priority.
The team estimates features in points (Fibonacci or East Agile scale).
The system auto-plans iterations from velocity.
The team starts stories from the top of the Current column.

That’s it. The “game” lives in the conversation; the tracker just keeps the score.

Small Releases → Releases (the story type)

XP says release often. Release is one of the four story types in East Agile Tracker. Create a release for every shipping milestone; drag it into the iteration where it ships. Releases skip Started/Finished/Delivered and go straight to Accepted when you ship.

Continuous Integration → Story state machine

The state machine isn’t CI per se — that’s your build system — but the Finished → Delivered → Accepted path mirrors the customer-acceptance loop XP describes. Finish the work, deliver it to the customer, accept when it’s confirmed working.

Velocity → “Yesterday’s weather”

XP calls it yesterday’s weather: how much you got done last iteration is the best prediction of how much you’ll get done this one. East Agile Tracker calculates velocity automatically — average of recent iterations, configurable strategy — and uses it to auto-plan the next iteration’s capacity.

Acceptance Tests → Reviews

Story reviews in the tracker map to acceptance. Assign a reviewer (the customer, the product owner, or even an agent acting as one). They approve or reject. Rejected sends the story back to Started.

Pair Programming → Co-ownership

XP teams pair on code. In the tracker, this shows up as multiple owners on a story. Assign both pairs to the story; both names appear on the card.

XP with agents — the new practice

XP was written before AI agents could meaningfully contribute to software. We think this is the most important update to XP in twenty-five years.

In our practice — and what the tracker is built for — an agent is a named XP team member. It has its own role, its own pair partner (human or agent), and its own audit trail. It can do anything a human team member can do in the planning surface: estimate, own stories, comment, transition, accept reviews.

The XP values still hold. Communication: agents communicate by reading the event stream and posting comments. Simplicity: agents are constrained to roles you grant them. Feedback: every agent action is in the audit log, immediately reviewable. Courage: be honest about what your agents got right and what they didn’t. Respect: agent teammates contribute value — recognize it.

We don’t put the agents inside the tracker doing the coding. We give the planning surface to humans and agents working together. You bring the coding agent — Claude Code, Codex, your own — and connect it to the tracker via the API. The agent picks up stories, does the work, comments, transitions. You review the trail and accept.

This is Inclusive Agile Planning. It is XP, with the team it actually has.