Appendix. Glossary

Where possible, XP uses widely accepted vocabulary. Where there are concepts in XP that are significantly different from concepts elsewhere, we highlight the differences by using new words. Here are the most important words in the XP lexicon.

Automated test

A test case that runs without any human intervention. The test checks to make sure the system calculates the expected values.

Coach

A role on the team for someone who watches the process as a whole and calls the team's attention to impending problems or opportunities for improvement.

Commitment schedule

A release and a date. The commitment schedule is refined one iteration at a time, and modified through reestimation and recovery.

Customer

A role on the team for choosing what stories the system has to satisfy, what stories are needed first and what can be deferred, and for defining tests to verify the correct functioning of the stories.

Engineering task

One thing the programmer knows the system must do. Tasks must be estimable at between one to three ideal programming days. Most tasks will derive directly from stories.

Entropy

The tendency of a system to get buggier over time, and for changes to become much more expensive.

Exploration

The phase of development when the customer communicates generally what all the system could do.

Functional test

A test written from the perspective of the customer.

Ideal programming time

The measure of an estimation tactic where you ask yourself, "How long would this take without distractions and disasters?"

Iteration

A one- to four-week period. At the beginning, the customer chooses the stories to be implemented in the iteration. At the end the customer can run their functional tests to see if the iteration succeeded.

Iteration plan

A pile of stories and a pile of tasks. Programmers sign up for tasks and estimate them.

Load factor

The measured ratio between ideal programming time and the calendar. Typically between 2 and 4.

Manager

A role on the team for allocating resources.

Pair programming

A programming technique where two people program with one keyboard, one mouse, and one monitor. In XP the pairs typically change a couple of times a day.

Partner

The other person who is pair programming with you.

Planning Game

The XP planning process. Business gets to specify what the system needs to do. Development specifies how much each feature costs and what budget is available per day/week/month.

Production

The phase of development when the customer is actually making money with the system.

Programmer

A role on the team for someone who analyzes, designs, tests, programs, and integrates.

Recovery

A planning move where the customer preserves the completion date of a release by reducing the scope of the release in response to increased estimates or decreased team speed.

Reestimation

A planning move where the team reestimates all the stories remaining in the release.

Refactoring

A change to the system that leaves its behavior unchanged, but enhances some nonfunctional quality—simplicity, flexibility, understandability, performance.

Release

A pile of stories that together make business sense.

Story

One thing the customer wants the system to do. Stories should be estimable at between one to five ideal programming weeks. Stories should be testable.

System metaphor

A story that everyone—customers, programmers, and managers—can tell about how the system works.

Team speed

The number of ideal programming weeks the team can produce in a given amount of time.

Test case

An automated set of stimuli and responses for the system. Each test case should leave the system the way it found it, so tests can run independently of each other.

Tracker

A role on the team for measuring progress with numbers.

Unit test

A test written from the perspective of the programmer.