Extreme Programming (XP) at a Glance

Note: This article is updated at Extreme Programming at a Glance.

Extreme Programming (XP) is a lightweight software development methodology based on principles of simplicity, communication, feedback, and courage.   I like to be able to scan methodologies to compare approaches.  To do so, I create a skeleton of the activities, artifacts, principles, and practices.    Here are my notes on XP:


  • Coding
  • Testing
  • Listening
  • Designing


  • Acceptance tests
  • Code
  • Iteration plan
  • Release and iteration plans
  • Stories
  • Story cards
  • Statistics about the number of tests, stories per iteration, etc.
  • Unit tests
  • Working code every iteration

12 Practices
Here's the 12 XP practices:

  • Coding Standards
  • Collective Ownership
  • Continuous Integration
  • On-Site Customer
  • Pair Programming
  • Planning Game
  • Refactoring
  • Short Releases
  • Simple Design
  • Sustainable Pace
  • System Metaphor
  • Test-Driven Development

For a visual of the XP practices, see a picture of the Practices and Main Cycles of XP.

5 Values (Extreme Programming Explained)

  • Communication
  • Courage
  • Feedback
  • Respect
  • Simplicity

The following are phases of an XP project life cycle.

  • Exploration Phase
  • Planning Phase
  • Iteration to Release Phase
  • Productionizing Phase
  • Maintenance Phase

For a visual overview, see Agile Modeling Throughout the XP Lifecycle.

12 Principles (Agile Manifesto)

These are the 12 Agile principles according to the  Agile Manifesto:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.   The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
4 Values (Agile Manifesto)

These are the four Agile values according to the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Additional Resources
My Related Posts
Comments (3)

  1. nitroxn says:

    Please provide a more in depth details of the processes so that they can be adopted for practical use.

  2. Agile says:

    Would like to read some stories where Agile, XP.

    What scenarios or project types should avoid these methodologies?

  3. J.D. Meier says:

    @ nitroxn

    eXtreme Programming Explained by Kent Beck does the job.  You can also check out http://www.extremeprogramming.org.

    @ Agile

    The rule of thumb is that if you know exactly what you need to build (i.e. you’ve built the same thing many times before), you don’t need agile.  The book Scenarios, Stories, and Use Cases by Ian Alexander provides a nice frame for analyzing your meta-process: evolutionary, incremental, and high risk.

    I don’t look at it as avoiding methodologies — instead, I look at it as what tools from the toolbox can I borrow that work for me.  For example, I like using stories to put requirements in context and for prioritizing value.

Skip to main content