BlogTemplates
Sprint retrospective agenda template
This sprint retrospective agenda template helps a software team review the last sprint, examine a change it tried and choose a next experiment with a measure and review date. The sample timings are editorial suggestions, and a 60-minute retro is not a Scrum Guide rule. Until the whole team agrees to an experiment, keep it marked as a proposal.
Short answer
- Review the sprint broadly before choosing an experiment or problem to examine.
- Label each possible cause as a hypothesis; retain evidence that challenges it.
- Give the next experiment a measure and review date; mark a missing baseline unknown.
- Leave disputed causes and unassigned work marked unresolved.
How do you run a sprint retrospective agenda?
- For
- A software team closing a sprint
- What it does
- Reviews one experiment, questions its possible causes and picks a measurable next change.
- Works in
- Plain Markdown; paste into any notes or docs app
Disclosure. Candor is an app that will compete with some products named here. We describe every product, including Candor, from its own documentation, and we'll test them all with the same published method.
You can join the Candor waitlist at candor.inc. This is a copyable worksheet, not a demonstrated output from the app.
Use the Copy button on the blank block, or select it and paste it into your document as plain text.
Template
Sprint retrospective agenda
## Meeting details
- Team or product:
- Sprint / period reviewed:
- Date, time and time zone:
- Facilitator, if any:
- Agenda owner:
- Participants:
- Chosen timebox and section timeboxes:
- Sprint Goal or intended outcome:
## 1. Set the scope
- What went well, what was difficult, and what remains unsolved?
- Which issue needs discussion most?
- What part of the sprint are we reviewing?
- Evidence or work-item links to have open:
## 2. Experiment reviewed
- Experiment or change tried (write "none" if there was none):
- When and where it ran:
- Intended result:
- Evidence to inspect (links, dates, sample or scope):
- Observed result, written as facts:
- What remains unknown or disputed:
## 3. Root-cause hypothesis
- Problem or variation the team wants to explain:
- Hypothesis about a contributing cause (label as a hypothesis):
- Evidence that supports it:
- Evidence that could weaken it or another plausible cause:
- What the team has not established:
## 4. Next experiment
- Proposed small change to try:
- Proposed coordinator (confirm acceptance in the meeting):
- Start and end point / sprint:
- Next experiment measure (definition and eligible work):
- Baseline and source:
- Missing data and unfinished work to report:
- Expected signal or threshold:
- When and where to review the result:
- Risks, dependencies or rollback point:
## 5. Close the discussion
Complete these fields during the meeting, then transfer accepted work to the action tracker.
- Decisions the team agreed to:
- Proposals that still need agreement:
- Open questions and who will bring evidence:
- Follow-up action, owner and due date (only if agreed):
Fill preparation fields before the meeting. Keep proposed changes labelled proposed; leave the closing decisions blank until the discussion happens.
Filled example
Fictional example: every person, event, reference and number below is invented. This is a prepared agenda; its closing fields remain unresolved.
Cedar Build, sprint 7 retrospective
Meeting details: Cedar Build; sprint 7, 12–23 October 2026, ending with this retrospective on 23 October, 13:00–14:00 IST. Participants: the four-person Scrum Team, Leena Kapoor, Omar Das, Nina Bose and Tejas Mehta. Leena leads the discussion; Omar owns the agenda. Sprint Goal: let customers resume interrupted uploads. Proposed timings: 10 minutes for scope, 15 for evidence, 15 for hypotheses, 15 for the next experiment and 5 to close.
Scope: preparation notes credit a passing upload-recovery test; slow reviews remain unresolved. Ask what else went well or needs attention before choosing review delay as the focus. Evidence: fictional report CB-REV-7, captured 23 October at noon, and the sprint board.
Experiment reviewed: a shared 30-minute review slot each working day in sprint 7, intended to shorten first-review waits. The fictional report lists 12 eligible pull requests: 11 received a first substantive human comment, with a median of 6 elapsed calendar hours from ready-for-review; one is still waiting, aged 20 hours. Slot attendance was not recorded, so whether the slot helped is unknown.
Root-cause hypothesis: unassigned first reviews may explain some waits. The report shows delays but lacks assignment history; supporting evidence for that cause is unknown. Compare waits for assigned and unassigned requests. Larger patches are another possible explanation. A long wait despite immediate assignment would weaken the ownership hypothesis.
Next experiment proposed: name a first reviewer when each request becomes ready. Ask Omar to coordinate; acceptance is pending. Proposed period: sprint 8, until 6 November; review at that sprint's retrospective. Measure elapsed calendar hours from ready-for-review to first substantive human comment for all non-draft pull requests marked ready during the sprint. The 6-hour baseline covers only the 11 reviewed requests. Report the eligible count, missing timestamps and the ages of requests still waiting. Proposed signal: median at most 4 hours, with no request waiting over 24 hours. If any request passes 24 hours, pause the experiment and ask the team to reassign it. Reviewer availability is a dependency.
Close, to complete in the meeting: decisions not yet made; experiment proposed; assignment history and the waiting request unresolved; evidence owner and follow-up dates not yet agreed.
When to use this
Use this when your software team needs to inspect how it worked and choose an improvement. In Scrum, the retrospective concludes the sprint; its maximum timebox is three hours for a one-month sprint, and it is usually shorter for shorter sprints. The Guide includes people and interactions in that inspection, as well as working practices and the Definition of Done. Keep the opening discussion broad. [1]
If nothing was tried last sprint, write “none” and use an observed problem to propose the first experiment. You can try a reversible change while its cause remains uncertain.
For a product-outcome discussion with stakeholders, use a Sprint Review agenda instead. Scrum gives that event a separate purpose. [1] Use the action-items minutes hub after the retrospective for accepted work.
What to customise
Choose section lengths with the team. Remove unused role fields; if no earlier experiment exists, skip its result fields. Add another issue if the opening discussion finds a more pressing problem.
Replace fictional references with your own sources. Define whether waits use working hours or elapsed hours, and keep that definition unchanged between baseline and follow-up. If the baseline is missing, collect it before judging a change.
Field-by-field guidance
| Field | What to enter | Where to get it | Common mistake |
|---|---|---|---|
| Meeting details | Team, participants, roles, sprint dates, meeting time with zone, goal and timeboxes | Sprint record and team agreement | Treating 60 minutes as a Scrum rule |
| Scope | What went well, difficulties, unresolved issues and the chosen focus | Sprint board and participants | Choosing a cause before hearing the team |
| Experiment reviewed | Change tried, period, intended result and evidence link | Prior retro action, issue, pull request or report | Calling an activity an experiment without saying what result it was meant to change |
| Observed result | What the linked evidence says, including scope and missing data | Report or source record | Turning a before/after difference into a cause claim |
| Root-cause hypothesis | One possible cause, with evidence for and against it | Team observations and linked records | Recording the first plausible explanation as an established cause |
| Next experiment | Proposed change and coordinator, period, risks and stop condition | Discussion and team capacity | Assigning work to someone who has not agreed |
| Next experiment measure | Definition, eligible work, baseline/source, missing data, threshold and review point | Report definition or collection plan | Omitting work still waiting from the report |
| Close | Agreed decisions, separate proposals, open questions and accepted follow-ups | The team’s read-back at the end | Writing a suggestion as a decision or filling in an unknown date |
A lower median alone cannot establish a cause. Smaller patches could shorten waits too. Report unfinished requests alongside the median: timing only served diners leaves everyone still waiting outside the restaurant out of the count. (The slowest request may still be open.)
Voice and AI workflow
- Before the meeting, dictate preparation notes into your document, including evidence references.
- Remove confidential or identifying data before pasting notes into an AI service.
- Ask for the agenda below, then check every factual claim against its source. Confirm names and proposed dates with the people involved; leave closing decisions pending.
- Afterward, confirm accepted work before adding it to the tracker. See minutes from a transcript and recording meetings if using an authorised recording.
Copyable prompt:
Reader: remove confidential or identifying data before pasting notes here. A person must confirm every name, decision and due date before sharing or acting on the output.
Turn these preparation notes into a Markdown sprint retrospective agenda. Include meeting details (team, sprint/period, date/time/zone, participants, discussion leader, agenda owner, timeboxes and goal); scope (what went well, difficulties, unresolved issues, chosen focus and source links); experiment reviewed (change, period, intended result, evidence with scope/dates, observed facts and unknowns); root-cause hypothesis (problem, possible contributing cause, supporting evidence, counter-evidence or alternatives, and what is unestablished); proposed next experiment (change, coordinator pending acceptance, period, risks/dependencies and stop point); next experiment measure (definition, eligible work, baseline/source, missing data and unfinished work, threshold, review date/place); and closing fields for agreed decisions, separate proposals, open evidence questions and accepted follow-ups with owners/due dates.
Keep closing decisions pending until the meeting happens. Preserve unknowns as unknown and source references beside their claims. Do not invent results, causes, names, source links, commitments or dates. Label proposals as proposals. Human confirmation is required for every decision, name, owner and due date.
Preparation notes:
What this page can't tell you
The worksheet cannot prove a cause or verify an AI output. A before/after change can have several explanations. This page reports no product tests or measured team outcomes; its example is fictional.
Questions
Has anyone found an AI tool that pulls action items from meeting notes without adding tasks nobody agreed to?
Keep proposed experiments separate from agreed actions until the team confirms them. The template leaves the action owner and follow-up fields open until acceptance and agreement.
How do you make sure sprint retrospective improvements actually stick?
Give the proposed experiment a measure and review date, then check its result at a later retrospective. The template also asks you to record unfinished work and missing data.
How do you handle retrospective actions that depend on another team?
Record the dependency, the next check and the effect it may have on the plan. Keep the action proposed until an owner and date are agreed.
About this page
Candor is being built as personal voice intelligence for everyone. You can join the Candor waitlist at candor.inc. Candor's own documentation is at candor.inc/docs.
Candor's docs on this page's topic: What the summary includes.
Last checked: 4 November 2026. Report an error to support@candor.inc.
Sources
- The 2020 Scrum Guide — https://scrumguides.org/scrum-guide.html#sprint-retrospective — checked 2026-11-04