Extreme programming, or XP, connects software engineering practices to short feedback loops: clarify a user need, test an example, build a small change and inspect the result together. Evaluate it by tracing a real decision through those loops. A board of tasks alone does not show whether the engineering feedback is working.
For a business commissioning software, the useful question is practical: when a requirement is misunderstood, how soon will someone notice, and who can decide what happens next? For a developer, the corresponding question is which test, conversation or review will expose that misunderstanding before more work builds on it.
The original worksheet below follows one small feature through those decisions. It uses XP-specific accounts by Ron Jeffries and Agile Alliance, rather than treating a generic agile meeting schedule as the method. You can use it to discuss an existing team’s practices or plan a bounded trial.
What makes XP an engineering approach?
Agile Alliance describes XP practices as an interconnected set. That is the central point of its XP explanation: practices should be understood in relation to one another. A test can support a design change, while a shared understanding of the requirement gives the test something meaningful to check.
Jeffries describes an XP team forming around a business representative called the Customer. In his account of extreme programming, that person helps steer the work. Establish who can make the equivalent business decisions on your project. Several stakeholders may contribute information, but conflicting instructions still need a clear resolution route.
Agile Alliance describes stories as short descriptions of things users want to do. Treat the story as an invitation to clarify behaviour. A brief line such as “request a callback” leaves unanswered questions about missing contact details, repeated requests and what the user sees afterwards. Those questions are useful development work, not distractions from writing code.
The Agile Manifesto principles identify working software as the primary measure of progress. That general agile principle supports reviewing behaviour that runs. The XP practices give the team specific ways to produce, inspect and change that behaviour; a written specification or a count of completed tasks is a different kind of evidence.
Which feedback loop answers which question?
In Jeffries’s account, the Customer defines automated acceptance tests for desired features. These concern whether the feature does what the business expects. Ask the business representative to explain the examples in ordinary language before the team discusses how to automate them. Agreement on the example is the starting point.
Jeffries describes test-driven development as short cycles of adding a test and making it work. Programmer tests can focus on a smaller piece of behaviour than the customer’s example. Keep their purposes visible: a passing small test is useful evidence about that piece, while the broader acceptance example checks the intended user outcome.
Jeffries describes production programming in pairs at the same machine. Use the pairing discussion to challenge assumptions while the implementation is taking shape. In an evaluation, ask what the pair is checking together and how unfamiliar parts of the system are understood. Simply assigning two names to a ticket does not describe that interaction.
Agile Alliance describes continuous integration as testing changes when added to a larger codebase. The larger system provides another feedback loop. A change that works in isolation can still reveal a disagreement at an interface. Record what failed and what decision resolved it, rather than treating integration as an administrative handover.
| Loop | Question it should answer | Evidence to retain in the trial |
|---|---|---|
| Story conversation | What behaviour does the user need? | Agreed example and unresolved questions |
| Acceptance example | Does the feature satisfy that example? | Input, expected outcome and observed result |
| Programmer test | Does this small behaviour work as intended? | Relevant failing and passing test output |
| Pairing | Are assumptions and code understood together? | Decision note for a disputed implementation choice |
| Integration | Does the change work with the surrounding system? | Combined test result and explanation of failures |
| Customer review | What should change after seeing it run? | Accepted behaviour or a newly prioritised example |
Original worked trace: a callback request with missing details
This hypothetical exercise concerns a small callback form. It is a learning artefact, with invented inputs and no claim that a production form or customer project behaved this way. Use a separate test copy and keep personal data out of the exercise.
Write the user outcome. The story is: a visitor can request a callback and understand whether the request was accepted. Ask the business representative what contact information is necessary. For the exercise, agree that a missing contact value produces an explanation and leaves the visitor able to correct the entry.
Make the acceptance example concrete. Write two rows on the worksheet: a request with the agreed contact value, and a request without it. Beside each, write the visible outcome before implementation starts. The absence of a contact value is a chosen example, not a universal rule about which contact methods every business must require.
Choose a small programmer test. The pair selects the validation behaviour and writes a test that expects the missing value to be rejected with the agreed reason. Run it before adding the new behaviour. Keep the initial failure understandable: a failure caused by a broken test setup teaches something different from an absent validation rule.
Implement and discuss. Add the smallest change that makes this test pass within the agreed design. Have the pair explain why the rule belongs in that location. Record any disagreement about duplicated checks or responsibility for the error message. This note gives the next reviewer a reason for the implementation, rather than just its final shape.
Integrate and inspect. Run the relevant combined tests in the trial environment. Introduce a mismatch in the exercise: the surrounding interface expects a different error field. Write down which integration check reveals it. Resolve the interface agreement and rerun the affected checks before calling that step complete.
Return to the business decision. Show the working correction flow. Suppose the representative now wants the form to retain the visitor’s other entries after an error. Add that as an explicit example and decide its priority. The useful output is a recorded change of understanding, rather than a claim that the original story predicted every detail.
How do refactoring and shared ownership support the loop?
Agile Alliance identifies removing duplication as a recommended use of refactoring. In the callback exercise, ask whether the same validation decision has appeared in several places. Keep the agreed behaviour constant while discussing a clearer design. Add a separate acceptance example if the intended behaviour itself needs to change.
Jeffries describes collective ownership as allowing any pair to improve any code. Jeffries links a common coding standard to code that looks familiar across the system. Read those practices together: shared responsibility needs a comprehensible codebase and a deliberate way to check changes. The trial should reveal whether another pair can follow the decision and work safely with it.
Use a simple handover challenge. Ask a pair who did not implement the callback rule to locate the relevant tests and explain the retained-entry requirement. Note where they need help. That observation can guide documentation or design improvements without inventing a productivity score for the method.
What should you decide after the trial?
Complete the trace with four entries for each loop: the question asked, the evidence obtained, the decision made and its owner. Where a loop produced no usable feedback, identify the missing ingredient. It may be an unavailable business decision-maker, an ambiguous example or a test that checks the wrong behaviour.
Choose the next improvement from that evidence. Keep the distinction between adopting a practice and demonstrating its intended contribution. To connect this discussion with the interface itself, see AJAX requests and accessible feedback. For project scope, read web development and get started with the story trace and the decisions your team still needs to resolve.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.