The Sprint Retrospective Facilitator: Turn Messy Team Notes Into Three Testable Experiments
Why this prompt matters
Retrospectives that end without concrete experiments repeat the same complaints every sprint. When action items are vague or too large, nobody finishes them, and the team learns that retrospectives change nothing. Three testable experiments with checkpoints break that cycle.
What we use it for
Your team's sprint ended with two stories missed and a retrospective board full of sticky-note comments. You have 20 minutes to prepare a summary and three experiments before the next planning session tomorrow morning.
Prompt
Role: Act as an experienced agile coach who facilitates sprint retrospectives for [TEAM TYPE, e.g. product engineering] teams of [NUMBER] people. Context: I will paste raw retrospective notes below. They are unstructured: sticky-note style comments, half-finished sentences, and some disagreement between team members. The sprint goal was [SPRINT GOAL] and the outcome was [COMPLETED / PARTIALLY COMPLETED / MISSED]. The team has run retrospectives before, and past action items were [DESCRIBE WHAT HAPPENED TO PREVIOUS ACTION ITEMS, e.g. mostly never finished]. Our retrospective is blameless and focuses on the process, not on individuals. Task: Turn the notes into a retrospective summary with three parts. First, group the notes into no more than five themes and name each theme in plain language. Second, identify the single most important pattern across themes, and state whether it is a process problem, a tooling problem, a communication problem, or a planning problem. Third, propose exactly three experiments for the next sprint. Each experiment must be small enough to finish within one sprint. Constraints: - Do not propose more than three experiments, even if the notes suggest more. - Each experiment needs a hypothesis in the form: We believe [change] will [expected result], and we will know this is true if [measurable signal]. - Each experiment needs an owner role, not a named person, and a checkpoint date within the sprint. - If a past action item appears again in the notes, flag it as a recurring issue and explain what would need to change for it to finally close. - Do not invent facts. If a theme is supported by only one comment, label it [WEAK SIGNAL]. - Keep the summary under [WORD LIMIT, e.g. 500] words. Output format: Markdown with three H2 sections: Themes, Core pattern, and Experiments for next sprint. Under Experiments, use a numbered list. End with a short list titled Questions for the facilitator, containing anything in the notes that is too ambiguous to act on. Raw notes: [PASTE RETROSPECTIVE NOTES HERE]
Result
Themes
- Review bottleneck slowed delivery. Four of the eleven stories sat in review for more than two working days. Two comments mention reviewers being pulled into an unplanned incident. [INFERRED: review capacity, not review quality, is the constraint.]
- Estimates were optimistic for integration work. The payment-webhook story was estimated at three points and took nine. Several comments say the dependency on the billing team was not mentioned during planning.
- Standup updates became status reports. Three people wrote that standups ran long because individuals explained blockers in detail that could have been handled in a separate thread.
- Test environment instability. Two comments describe the staging database being reset without notice. [WEAK SIGNAL: only two mentions, but both describe lost work.]
Core pattern
The main pattern is a planning problem with a review-capacity root cause. Work was committed without checking whether reviewers and dependent teams had room for it. This is a planning problem first, because the team could have seen the dependency and the review load before the sprint started, and a tooling problem second, because the staging instability made integration work slower than expected.
Experiments for next sprint
- Reserve review capacity. We believe setting aside two review slots per engineer per day will reduce average review wait time below one working day, and we will know this is true if the median time from PR open to first review is under 24 working hours by the sprint checkpoint on Wednesday. Owner: engineering manager.
- Flag cross-team dependencies in planning. We believe adding a dependency column to the planning board will reduce estimate overruns on integration stories, and we will know this is true if no story with an unlisted external dependency is committed. Owner: product owner. Checkpoint: mid-sprint review.
- Move blocker detail to a thread. We believe limiting standup updates to one sentence per person, with details posted to a blocker thread, will keep standups under 10 minutes, and we will know this is true if the timer shows under 10 minutes on at least four of five days. Owner: scrum master.
Questions for the facilitator
- Did the staging database reset affect the payment-webhook story, or was that a separate issue?
- Who owns the billing team relationship, and is there a named contact for dependency requests?
This prompt turns a retrospective board into a plan the team can actually run. It groups noisy comments into themes, names the pattern underneath them, and limits the output to three experiments, because teams that commit to more than three rarely finish any. Every experiment has a hypothesis, a measurable signal and a checkpoint inside the sprint, so the next retrospective can say whether it worked.
The example output above uses a fictional team. Replace the bracketed fields with your team type, sprint goal and outcome, describe what happened to previous action items, and paste the raw notes where indicated. The [WEAK SIGNAL] tag stops a single comment from becoming a priority, and the recurring-issue check catches action items that keep returning.