Extreme Programming


XP is a type of type of agile software development which is intended to improve software quality and responsiveness to changing customer requirements.

XP features:

  • Frequent releases in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted
  • Pair programming or extensive code review, unit testing of all code
  • Avoiding programming of features until they are actually needed
  • A flat management structure
  • Simplicity and clarity in code
  • Expecting changes in the customer's requirements as time passes and the problem is better understood
  • Frequent communication with the customer and among programmers


XP describes four basic activities that are performed within the software development process.



Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements. These occur in the exploration phase of release planning. A "testathon" is an event when programmers meet to do collaborative test writing, a kind of brainstorming relative to software testing.


Programmers must listen to what the customers need the system to do, what "business logic" is needed. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved.




XP favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.


Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later.


Feedback relates to different dimensions of the system development: feedback from the system by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes, feedback from the customer, from the functional tests (aka acceptance tests) written by the customer and the testers, feedback from the team when customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.
Feedback is closely related to communication and simplicity.


Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow, throwing code away, courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.


The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project.


Rules of engagement

  • Business people and developers do joint work
  • Our highest priority is customer satisfaction
  • Deliver working software frequently
  • Working software is the primary measure of progress.
  • At any point, any member of the team must be able to measure the team’s progress towards the customer’s objectives and the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • The team must act as an effective social network

Rules of Play



Extreme Programming has a number of practices, grouped into different areas:

Fine scale feedback

  • Pair programming: 2 programmers at the same machine. Driver and Observer switch roles every 30 min.
  • Planning game: The game is a meeting that occurs once per iteration.
  • Test-driven development
  • Whole team: Team consists of managers, programmers, designers, customer, etc.

Continuous process

  • Continuous integration
  • Refactoring or design improvement
  • Small releases

Shared understanding

  • Coding standards
  • Collective code ownership: This means that all code gets the benefit of many people’s attention, which increases code quality and reduces defects.
  • Simple design
  • System metaphor: The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only.

Programmer welfare

  • Sustainable pace: Teams work hard and at a pace that can be sustained indefinitely. The concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.


  • The customer is always available
  • Code the Unit test first
  • Only one pair integrates code at a time
  • Leave Optimization till last
  • No Overtime


  • All code must have Unit tests
  • All code must pass all Unit tests before it can be released.
  • When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
  • Acceptance tests are run often and the results are published

Project Velocity

The project velocity (or just velocity) is a measure of how much work is getting done on the project. To measure the project velocity you simply add up the estimates of the user stories/Tasks that were finished during the last iteration. Project velocity is the ratio between estimated time and real calender time.
During the iteration planning meeting customers are allowed to choose the same number of user stories equal to the project velocity measured in the previous iteration. Those stories are broken down into technical tasks and the team is allowed to sign up for the same number of tasks equal to the previous iteration's project velocity.

User Story

User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

The difference between traditional requirements specifications and user stories is the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.

Release Planning/Meeting

After user stories have been written you can use a release planning meeting to create a release plan. The release plan specifies which user stories are going to be implemented for each system release and dates for those releases. This gives a set of user stories for customers to choose from during the iteration planning meeting to be implemented during the next iteration. These selected stories are then translated into individual programming tasks to be implemented during the iteration to complete the stories.
Stories are also translated into acceptance tests during the iteration. These acceptance tests are run during this iteration, and subsequent iterations to verify when the stories are finished correctly and continue to work correctly.

The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks.

Iteration Planning

An iteration planning meeting is called at the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 to 3 weeks long. User stories are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.

Tasks are written down on index cards like user stories. While user stories are in the customer's language, tasks are in the developer's language. Duplicate tasks can be removed. These task cards will be the detailed plan for the iteration.

Developers sign up to do the tasks and then estimate how long their own tasks will take to complete.

Planning Game

The main planning process within Extreme Programming is called the Planning Game. The game is a meeting that occurs once per iteration. The planning process is divided into two parts:

Release Planning

This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the cost estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project.

Iteration Planning

This plans the activities and tasks of the developers. In this process the customer is not involved. The programmers break customer user stories down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License