Leave the retrospective with one test

Read the diagram as text

Use one observed event, choose a small experiment with an owner and agree what evidence to review next. Return to that evidence at the next retrospective.

A retrospective can feel productive and change nothing. Its useful output is a decision somebody can act on and revisit. Instead of collecting a long improvement backlog, take one recurring observation and design a small test around it. Preserve the other observations for later rather than pretending the team can act on all of them at once.

Bring the work into the room

Ask participants to bring a recent item, handoff or decision they can describe. An account of what happened is easier to investigate than a label such as “communication.” Give people a way to raise a concern without disclosing personal information to the group. Do not require a public story about an individual to demonstrate engagement.

The Agile Manifesto includes regular reflection followed by adjustment. The meeting format below is our proposal for turning that intention into a checkable team experiment. It is not a required ceremony or a validated scoring system.

A compact facilitation sequence

1. Recall: list observed events from a bounded period.
2. Clarify: separate what happened from possible explanations.
3. Select: choose one issue the group can influence.
4. Design: agree on a change, owner and expected mechanism.
5. Review: decide which evidence will inform the next decision.

Allow more time for clarification when accounts conflict. A facilitator should not settle a factual disagreement by voting on the more popular explanation. Keep the uncertainty and agree on an observation that could resolve it.

Illustrative test

Suppose an imaginary team repeatedly discovers missing acceptance details during testing. It proposes a brief review of the next few requests before implementation. The owner records which details were clarified, whether the review delayed urgent work and whether testing still surfaced the same gaps. The example has no claimed success rate because no real trial has been performed.

“Hold more meetings” would be too vague. “For the next suitable requests, the requester and tester review the acceptance example together before implementation” describes an action and a mechanism. Agree on what “suitable” means so people do not quietly exclude difficult cases after seeing the result.

Make the decision reversible

Set a point at which the group can modify or stop the change. A trial should not become permanent merely because nobody remembers who authorized it. If the change adds work, record what it replaces or how the additional burden will be reviewed. Invite the people affected outside the immediate team to contribute.

Open the next retrospective with the previous test

Ask what was actually tried and what was learned. A missed experiment needs a discussion of feasibility, not a fabricated outcome. If the evidence is mixed, say which observations conflict. The group can narrow the test or collect more comparable examples before concluding that it helped.

Observation:
Working explanation:
Change to try:
Owner and affected people:
Evidence to gather:
Review date:
Decision after review:

Use the A3 worksheet when the selected issue needs deeper problem framing. Read the archived Learning to Learn note for the earlier discussion. A small, documented learning cycle is easier to inspect than a growing list of promised improvements.

Review the missing records before reviewing the result

A stopping rule is useful only if the review can see what actually happened. Use a small evidence ledger to distinguish a trial that ran, one that was partly recorded and one that never started. The following record is invented; it reports no client or historical author’s results.

1. Bring the original trial card, including its eligibility rule and stopping condition. Keep its wording rather than rewriting it to fit the outcome.
2. List every eligible item in the agreed window. Mark performed, not performed or unknown; a blank row is not a successful trial.
3. Separate observations from interpretation and cost. Ask affected people whether work was displaced outside the team.
4. Choose continue, adapt or stop using the available evidence. If evidence is insufficient, specify what must be observed next rather than claiming improvement.

Completed teaching review: five requests were eligible for a pre-implementation acceptance check. Requests 1 and 2 were checked and a missing detail was clarified in each. Request 3 skipped the check because the reviewer was unavailable. Request 4 has no record. Request 5 was checked but still reached testing with an unclear example. Therefore three checks are confirmed, one was not performed and one is unknown. “Five checks completed” is unsupported.

Decision: adapt the reviewer-availability arrangement and collect the missing record; do not report a reduction in defects from this ledger. Reuse: item __; eligible why __; check performed/absent/unknown __; observed detail __; time or displaced work __; decision __. Counts of this invented trial do not establish a general causal effect.

Source: agilemanifesto.org.