For a small team, the facilitation plan below gives you a 45-minute starting point. Its timings are a proposal, not a Scrum requirement. Replace the sample observations with your team's actual experience before sending it.
A 45-minute plan for a six-person team
Illustrative example: all people, events, and counts in this section are fictional. The team finished Sprint 12. Its previous experiment was to include reproduction steps in bug reports. This time, it wants to examine why code reviews waited until the last two days.
| Minutes | Facilitation prompt | What to leave visible |
|---|---|---|
| 0-5 | Did we try the previous experiment? What evidence do we have? | Reproduction steps were included in four sample reports; review-time evidence is missing. |
| 5-12 | Write observations individually: what helped, what caused trouble, and what could change? | Three review requests arrived on the final Thursday; one lacked test instructions. |
| 12-22 | Group related observations, then clarify what happened. | “Late handoffs” and “unclear review requests” remain separate groups. |
| 22-32 | Which condition can we change in the next sprint? | Compare smaller review batches with clearer review instructions. |
| 32-40 | Agree on one experiment and define its check. | Smaller review batches; owner Maya; check at the Sprint 13 retrospective. |
| 40-45 | Read the commitment aloud and confirm where it will be tracked. | The experiment and evidence request go into the maintained sprint record. |
Start by checking whether the last experiment happened. “We added reproduction steps” answers that question; “it made us faster” requires separate evidence. If the evidence is absent, record that gap instead of declaring the experiment successful.
During individual reflection, ask for observable examples. “Review request opened Thursday afternoon” gives the team something to investigate. “People don't care about reviews” assigns a motive that the observation does not establish.
Follow the observation into the experiment
Keep the original observation beside the improvement. Otherwise, “use smaller batches” can become a detached process rule that nobody remembers choosing.
The sample experiment reads:
Observation: Three review requests arrived on the final Thursday of Sprint 12. The team has not yet established why they arrived late.
Hypothesis: Sending a reviewable slice earlier may expose review needs sooner.
Experiment: In Sprint 13, split suitable changes into independently reviewable slices and request review when each slice is ready. Do not split work in ways that prevent meaningful testing.
Owner: Maya will bring the experiment back for review; authors and reviewers agree how to try it.
Evidence: Record request time, first-review time, and whether each slice had enough context to review. Compare the observed cases without promising a speed improvement.
Check: Sprint 13 retrospective, October 30 in this fictional schedule. Decide whether to keep, modify, or stop the experiment.
An owner makes the follow-up findable. It does not make one person responsible for fixing the whole team's working conditions. Ask participants whether the experiment fits the work they expect next sprint and what might make the comparison misleading, such as absences or unusually small changes.
Keep the entire phase sequence in your reading copy so you can follow the meeting without losing the improvement commitment. Compare the delayed-review observation with the smaller-batch experiment, its evidence request, and its check date. Collect the team's real contributions in the notes or board you actually use.
Copy a prompt and add your sprint evidence
Create a sprint retrospective meeting agenda in US English for my Scrum Team.
Sprint and dates: [enter sprint and dates]
Participants: [enter team size and roles]
Meeting time available: [enter minutes]
Previous experiment and evidence: [paste, or write NOT SUPPLIED]
Observations from this sprint: [paste observable events; remove private details]
Constraints for next sprint: [enter known constraints]
Maintained record for agreed improvements: [enter location]
Allocate time to check the previous experiment, reflect individually, clarify
and group observations, choose an improvement, and confirm follow-up. Make
the phase times sum to the meeting length. Treat these timings as my plan,
not a required Scrum agenda.
Keep observations, interpretations, and proposed changes distinct. Preserve
the wording of supplied observations. Do not invent motives, causes, numbers,
votes, participant agreement, or past results. Mark missing evidence NOT
SUPPLIED. Draft one proposed experiment with its linked observation, owner
or OWNER TO CONFIRM, evidence to collect, and check date or DATE TO CONFIRM.
End with questions the team must answer before adopting it.
Return the agenda and experiment record as text. Then provide an optional
HTML reading version of the same material, with the full phase sequence
visible and a comparison of observations and the proposed experiment. Label
proposals clearly. Do not add comment collection, voting, or integrations.
Read the plan before facilitating it
Run through the prompts with a co-facilitator. If the discussion consumes the clarification block, decide what you will shorten while preserving time to name the experiment and its check. A list of complaints is not the intended stopping point.
If you use the HTML reading version, NOS can save and display it for that rehearsal. Look at the observation and proposed experiment together, then keep the team's agreed improvement in its maintained sprint record. At the next retrospective, bring back the evidence and decide what happens to the experiment.