• Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.
  • Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.
  • Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
  • Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes whenever they happen.
  • Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.



Plan & Manage

  • Release Plan: A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each iteration.
  • Iteration Plan: An iteration planning meeting happens in the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 week as best practice. 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.
    Each iteration essentially should look like the illustration below:
  • Manage: Management should give the team a dedicated open work space, set a sustainable pace. The team should have a stand up meeting to start each day. The Project Velocity is measured at the end of each iteration and fix the XP practices when it breaks.

Design and Development

The team should strive for simplicity, use system metaphors to describe the implementation and CRC cards for design sessions. They create spike solutions to reduce risk and don’t add functionality early. The team refactors whenever and wherever possible and implement test driven development strategies (TDD), automated testing framework, pair programming, and continuous integration and deployment.

Recommendations and Guidelines for XP Teams

  • Team size should be 5 or less people. This is important because the smaller the team the less communication channels, and thus more focus on getting the work done.
  • Iterations are one week long. Iterations are one week long because you want to constantly get feedback and interact with your customer. With a tightly coupled team, this is possible.
  • The Planning Game is a meeting at the beginning of each iteration to prioritize the work and get technical estimates – meant to be quick and dirty meeting as the plan can change if needed. Since the iterations are one week long and priorities can change within the iteration, you don’t want to spend too much time planning your commitment.
  • Look to release after every iteration if possible if your team is not apart of a group of teams tracking towards a common release. Like Scrum, you want every Sprint to be potential shippable code.
  • The scope within each iteration is flexible as long as the work has not been started. You want to give your customer the most amount of flexibility within reason. So, planned work that has not been started in an iteration should be flexible to change in priority or scope. This may require a conversation with customer mid iteration.
  • The team works in a strict priority order. Features to be developed are prioritized by the customer. Just like Scrum, we want to focus on business value (biggest bang for the buck) not scope and budget.
  • XP incorporates engineering practices, particularly things like test-driven development, automated testing, pair programming, simple design, refactoring, and so on. eXtreme Programming is all about being efficient and effective. Automation is key in achieving this. The more you can automate, without creating extra overhead, will improve the overall quality and make the team more efficient and effective in meeting their iteration commitments.
  • Have Daily 15 minute standups. Like Scrum, it’s the only time where tam can formally sync up to discuss their progress. A good stand up is not a status meeting but more a conversation about the progress made towards the iteration commitments.
  • Avoid having more than 40 hour work weeks. Statistics show that beyond insane number of hours is counterproductive as developers and QA alike will start to make mistakes and create more work.
  • As stories get completed, show your work to the customer to get them accepted and committed to the official code base. Just like Scrum, its all about customer satisfaction. The sooner they can see your progress, the sooner they can give feedback.
  • Have a Retrospective with your team at least once every three iterations. There will always be opportunities to improve. At the same time, you don’t want your teams to buried with meetings since the iterations are very short. So, keeping on every three weeks will not suffocate your team and they will see the value in doing a Retrospective.


Remember that Extreme Programming is an agile software-development methodology. XP helps you remain light on your feet by avoiding unnecessary baggage and by incorporating feedback continuously. Changing requirements are an expected and acceptable risk, because the customer sees the system being developed in real-time. Mistakes are immediately visible and are corrected while the feature’s implementation is fresh and pliable, much like a potter reworks clay.
Programmers work and rework the code in eXtreme Programming projects. The customer sees a system grow from layer upon layer of detail. The software is only as effective as the details it embodies. Details do matter, and eXtreme Programming reflect back to the customer in the only way that matters: working code.eXtreme Programming practices can also be adopted in other Agile frameworks like Scrum.
Below is a holistic summary of eXtreme Programming by Ron Jefferies:


Extreme Programming Explained: Embrace Change.
Author: Kent Beck. Published: September 2004. Publisher: Addison-Wesley Professional.

About Me

Sed pellentesque nibh enim, quis euismod enim lacinia nec. Phasellus quam diam, semper in erat eu. Consectetur adipiscing elit. Sed pellentesque nibh enim, quis euismod enim lacinia nec.