Extreme programming (XP) is an agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Fine scale feedback

Pair programming

Pair programming means that all the codes which is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers trade roles after minute to hour periods.

Extreme programming practices

The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership).

Extreme programming practices

Planning game

The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:

Extreme programming practices

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. Release Planning consists of three phases: Exploration Phase: In this phase the customer will provide a shortlist of high-value requirements for the system. These will be written down on user story cards. Commitment Phase: Within the commitment phase business and developers will commit themselves to the functionality that will be included and the date of the next release. Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed. Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases: Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards. Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated. Steering Phase: The tasks are performed and the end result is matched with the original user story.

The purpose of the Planning Game is to guide the product into delivery. Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery using a straightforward approach. The Planning Game approach has also been adopted by non-software projects and teams in the context of business agility.

Release planning

Exploration phase

This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.

Write a Story: Business has come with a problem; during a meeting, development will try to define this problem and get requirements. Based on the business problem, a story (user story) has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story. The story is written on a user story card. Estimate a Story: Development estimates how long it will take to implement the work implied by the story card. Development can also create spike solutions to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements. Split a Story: Every design critical complexity has to be addressed before starting the iteration planning. If development isn't able to estimate the story, it needs to be split up and written again.

When business cannot come up with any more requirements, one proceeds to the commitment phase.

Commitment phase

This phase involves the determination of costs, benefits, and schedule impact. It has four components:

Sort by Value: Business sorts the user stories by Business Value. Sort by Risk: Development sorts the stories by risk. Set Velocity: Development determines at what speed they can perform the project. Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined.