Once the planning is complete, the iteration begins. If a programmer doesn't already have a task, they take the next available one and find a partner. If necessary, design work will be carried out at this stage, including the use of Class Responsibility Collaborator (CRC) modeling of Object-Oriented Design (OOD), and other design tools such as UML Sequence Diagrams.
The pair will begin coding in theTDD way by writing a failing test. They then write the code that fulfills the test. Once the test is running, they then look to refactor the code, as the following diagram illustrates:
This cycle continues until the task is complete.
Each day the team will meet in the form of a Daily Standup; this is a 15-minute meeting where, as the name suggests, everyone stands. The aim is to coordinate the team's work. Each team member or pair will talk about what they've implemented since yesterday's standup, what they'll look to achieve before the next standup, and what, if anything, is in their way.
XPers aim to integrate early and often; they favor a practice called Continuous Integration (CI). They will typically commit work every few hours, providing, of course, all of their unit tests pass. Modern CI practices offer an automated way for the latest changes to be incorporated. Teams will often set up their CI server so that it automatically checks out the newest version, builds it, and runs the tests. Their practices and workflow shouldn't allow them to commit code and proceed unless all tests pass.
Once the story is complete, the software is made available for acceptance testing. The customer executes the scenarios they've created around the acceptance criteria of the User Story, so they can determine whether the software is complete. Many teams now automate their acceptance testing as part of their TDD approach, a technique known as Acceptance Test Driven Development (ATDD).