Kent Beck, author of Extreme Programming Explained says, "XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements." Simply stated, XP is a set of values, rights and best practices that support each other in incrementally developing software.

XP values Communication, Simplicity, Feedback and Courage.

The team has the right to do a quality job all the time, be honest with each other and to have a real life outside of work. Team members communicate with each other openly and honestly. Problems are solved simply, designs are kept simple. We get feedback by writing tests and showing the customer what was asked for. We need courage to be honest about what is possible, to improve a design when the pressure is on and to challenge the status quo.

XP is a collection of best practices. Some may sound familiar. Some may sound foreign.

Customer Team Member - Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product. I'll refer to this group of people as the customer or the customer team in this paper. The customer is responsible for acceptance testing the product. This means the customer team needs skilled testers.

User Story - A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration. If the story is too big to complete in an iteration, split it into smaller stories. If you are used to use cases, a story is like the name of a use case. The details of the use case are in the acceptance tests.

Planning Game - XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimate the effort to complete each story. Customers select stories and package them into iterations. Stories are prioritized by the customer according to their business value and cost.

Small Releases - Programmers build the system in small releases. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Acceptance Testing - The customer team writes acceptance tests. The tests demonstrate that the story is complete. Acceptance tests provide the details behind the story. Tests are defined prior to completing a story. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.

Open Workspace - To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.

Test Driven Design - Programmers write software in very small verifiable steps. First, a small test is written, followed by just enough code to satisfy the test. Then another test is written, and so on.

Metaphor - The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, helping the software communicate to the programmers.

Simple Design - The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don't build frameworks and infrastructure for the features that might be coming. Frameworks and infrastructure evolve as the application evolves.

Refactoring - As programmers add new features to the project, the design may start to get messy. If this continues, the design deteriorates. Refactoring is the process of keeping the design clean, incrementally. [FOWLER]

Continuous Integration - Programmers integrate and test the software many times a day. Big code branches and merges are avoided.

Pair Programming - Two programmers collaborate to solve one problem. Programming is not a spectator sport. Both programmers are engaged in the solution of the problem at hand.

Collective Ownership - The team owns the code. Programmer pairs modify any source code as needed. Extensive unit tests help protect the team from coding mistakes.

Coding Standards - The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style. Individuals may have to give up their favorite conventions to conform to the team style. The standard is determined by the team.

Sustainable Pace - The team needs to stay fresh to effectively produce software. Creating a product is like running a marathon. We sprint at times during the marathon, but we are careful to reserve our strength so that we can finish the race.