Skip to content
Product Lifecycle Templates

Sprint Retrospective Notes

beta  ·  Family process-docs  ·  Phase iterate  ·  Sizes lean  ·  ~2,800 tokens

The written record of a Sprint Retrospective: what the team says went well, what it says needs to improve, and which of those improvements someone actually owns. The Scrum Guide names only an event, never a document; this bundle exists to make one owned, dated change survive past the meeting that produced it.

The short card. Why the document is shaped this way, and the argument behind every rule here, is in sprint-retrospective-notes_companion.md. A fully worked instance is sprint-retrospective-notes_example.md.

When to use

Section titled “When to use”
  • A sprint just ended, or is about to end, and the team is holding its retrospective. Write these notes to make one improvement owned, dated, and findable again, not to produce a transcript of the meeting.
  • The team has run a retrospective before and produced action items last time. This document is where those items get checked against what actually happened, not only where this sprint’s items get written down.
  • More than one person needs to find the outcome later: a teammate who missed the meeting, someone who joins the team next quarter, or the same team three sprints from now wondering whether an idea was ever tried.
  • The team works on a Scrum or agile-lineage cadence and is looking back on a period, on a schedule, at how it worked, not reacting to one specific thing that broke.

When NOT to use

Section titled “When NOT to use”
  • The sprint contained an incident and you want to analyze why it happened. That is causal analysis of one event, not a look back at how the team worked across a whole sprint. Use the incident-postmortem member of this family for the analysis, and use this document only to name that the incident happened and point at where its analysis lives.
  • You are reviewing a release, a milestone, or a whole project, not one sprint. That is a different occasion with its own literature, not a bigger size of this sprint-scoped document. Reach for a release or project retrospective instead.
  • Nothing from this retrospective will actually be revisited. If the team will not reopen the Previous Actions table next time, this document records a discussion that commits nobody to anything, which is the exact failure this family of documents exists to prevent.
  • You need to run the retrospective itself. This is the written record of, or during, that discussion, not a facilitation guide, an icebreaker, or a set of exercises for structuring the conversation.
  • The team is not going to write anything down at all. A board that gets erased at the end of the meeting with no persisting record is not a smaller version of this document. If the outcome never gets written down, nothing here helps.

Pick a variant

Section titled “Pick a variant”

There is, honestly, no choice to make here. This bundle ships one file, and that is a finding rather than a shortcut, because no primary, standards, vendor, or academic source this research found publishes a second, heavier weight of a sprint retrospective notes document. The genuine variation the research did find is across occasions (a release or project retrospective is a different document with its own chapter in the literature), not across sizes of this sprint-scoped one. See section 4 of the companion for the case that was tested and rejected.

Use sprint-retrospective-notes_template-lean.md. There is no second file to reach for. The evidence that would have earned a heavier weight argues instead for a better single template, one whose columns ask for a reason and not only an observation, which is what this one does.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”

Score each 0, 1, or 2. Below 11 out of 16 and the document records what the team felt without producing a change anyone can be held to, the exact failure this family of documents exists to prevent.

# Criterion 0 1 2
1 Room named honestly No sprint identifier, or the list names who was invited Sprint named by its own identifier, but attendance conflates invited with present Sprint named by its own identifier, not just a date range, and the present list is distinct from who was invited
2 Previous actions checked Table missing or blank, or marked N/A without the one honest reason (a true first retrospective) Some rows from the previous Action Items table carried forward, but at least one is silently missing Every row from the previous retrospective’s Action Items table appears here with a status, and every not-done row carries one honest line on why
3 Went well says why Entries are morale words with no practice named (“good week”) A specific practice is named, but with no stated reason it helped Every practice entry states why it worked, concrete enough that someone who was not in the room could repeat it on purpose
4 Problems carry an idea A problem is stated with nothing attached to it An idea is attached to some problems, others are left floating Every problem names both why it happened and at least one candidate idea for changing it
5 Actions are owned A row has no owner, no date, or names a team rather than a person Owner and date are present, but the row does not connect to a problem or idea named above Every row names a person, a date, and traces back to a specific problem or idea named earlier in the document
6 Actions pass payback An action too small to be worth tracking, or so large it will never be checked done Sized right, but not stated in a way anyone could check done or not Every action is checkable done-or-not and could plausibly justify the retrospective time spent finding it
7 Scope stays in-sprint The notes narrate the causal analysis of a specific failure, why one thing broke, rather than how the team worked An incident is mentioned but not explicitly pointed at the postmortem, or the boundary is implied rather than stated If the sprint contained an incident, it is named plainly and its causal analysis is pointed explicitly at the incident-postmortem member of this family; if none occurred, nothing here reads like one anyway
8 Specific without assigning blame A row names a person as the cause of a problem, or is vague enough to say nothing checkable The practice or problem is specific, but the wording still reads as pointed at a person Every entry is specific about what happened and stays aimed at the practice or the system, never at a person

The test behind every cell above: could someone satisfy it without improving the document? A row that counted rows in a table, or counted how many action items were listed, would reward padding. Every cell instead asks whether a specific piece of evidence exists, and whether a second person, not the author, could find it and check it.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. Action items nobody checks. A failure named independently by two of the sources behind this bundle: an action item lands in one retrospective’s notes and nobody looks at it again. Previous Actions exists precisely to catch this; leaving it blank or perfunctory reopens the exact gap it was built to close.
  2. An action item with no owner. A row with no name attached is an observation wearing an action item’s clothing. The team can agree something should change and still produce nothing, because nobody owns doing it.
  3. The retrospective as the first casualty of time pressure. Cutting the retrospective whenever the sprint runs long teaches the team that this document is optional, and it stops being read the moment it stops being reliably written.
  4. Blame despite the intent to be blameless. A retrospective that turns into whose fault something was, instead of what pattern the team wants to change, costs the willingness to speak honestly next time, and the notes read as a grievance list rather than a working document.
  5. Discussion with no follow-through. Naming a problem and then not acting on it, sprint after sprint, teaches the team that raising an issue changes nothing. This is distinct from an unowned action item: the item may even have an owner and a date and still never get done.
  6. Reflection without a reason. A “what went well” or “what to improve” entry that states only what happened, never why, cannot be repeated on purpose or avoided on purpose. This is the dominant pattern the research behind this bundle found in real retrospective content, and it is the specific failure the Why columns in this document are built to answer.
  7. Retrospective and postmortem, run on the wrong occasion. Running this document’s discussion on an incident produces a discussion of a thing that needed causal analysis; running a postmortem’s causal analysis on an ordinary sprint pathologizes normal work. Keep the trigger straight: a period, on a cadence, against an event, triggered by it.
  8. An unvarying format, sprint after sprint. The same three questions asked the same way stop producing new information once the team can predict its own answers before the meeting starts. If what comes back has stopped changing, the format is due for a change, not the team.

Pairing with your process

Section titled “Pairing with your process”

This bundle ships in the process-docs family alongside the incident postmortem. The two exist to be told apart by trigger, not by tone: this document looks back on a period, on a cadence, at how the team worked; the postmortem looks back on an event, triggered by it, at why one specific thing failed. If a sprint contained an incident, write it up once, in the postmortem, and point to it from here rather than duplicating the causal analysis in both places.

The artifacts

Section titled “The artifacts”

sprint-retrospective-notes_template-lean.md · ~2,800 tokens

---
title: "{{sprint_id}} Retrospective Notes"
doc_type: sprint-retrospective-notes
size: lean
sprint: "{{sprint_id}}"
team: "{{team_name}}"
facilitator: "{{facilitator}}"
status: draft
doc_version: "{{doc_version}}"
created: "{{date}}"
updated: "{{date}}"
related_links: []
source_template: sprint-retrospective-notes
source_template_version: 0.1.0
---


<!--
LEAN SPRINT RETROSPECTIVE NOTES. The whole artifact: which sprint this covers and who was in the room, what
last retrospective's action items actually became, what worked, what did not, and what will change. This
bundle ships one size. No primary, standards, or academic source publishes a heavier version of this
document, and the real variation in the literature this research read is across occasions, a release or
project retrospective is a different document, not a bigger size of this sprint-scoped one. See
sprint-retrospective-notes_companion.md section 4 (Variants and sizing).


A SPRINT RETROSPECTIVE NOTES DOCUMENT EXISTS TO MAKE ONE IMPROVEMENT OWNED, DATED, AND FINDABLE AGAIN. The
Scrum Guide names an event, never a document, and in its 2020 rewrite it downgraded the one mechanism that
used to carry retrospective output forward: what the 2017 Guide required, the current Guide only permits.
The largest study of retrospective content this research read found that the large majority of statements
gave no reason at all, and unowned, unchecked action items are the single most-named failure mode in the
practitioner literature behind this bundle. Every section below answers one of those two problems. See
sprint-retrospective-notes_companion.md sections 1, 2, and 7.


THIS IS NOT AN INCIDENT POSTMORTEM. If this sprint contained an incident, name it here and record its causal
analysis in the incident-postmortem member of this family instead; keep this document scoped to how the team
worked across the whole sprint, not to why one specific thing failed. See sprint-retrospective-notes_companion.md
section 8 (Relationships to other artifacts).


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   sprint-retrospective-notes_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a
   WEAK example, and the TRAP to avoid. For each table, PRIORITY explains the ordering and ROW HINT says
   what a good row contains.
2. Replace each {{placeholder}} with your content.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it. An empty Previous
   Actions table on a team's first retrospective is not an N/A: write "First retrospective for this team, no
   prior actions to check" as the row instead.
4. Before you share it: self-grade against sprint-retrospective-notes_guide.md, then DELETE every HTML
   comment. They are guidance, not content.
-->


# {{sprint_id}} Retrospective Notes


## Sprint and Participants


<!-- WHAT  The identifying header: which sprint this retrospective covers, when it was held, who
           facilitated it, and who was actually in the room.
     WHY   This renders Documentero's own "Meeting Information" heading for a sprint context. No source
           this research read argues against recording this; it is the least contested section in the
           document. Deep dive: sprint-retrospective-notes_companion.md section 3 (Anatomy > Sprint and
           Participants).
     ASK   Which sprint does this cover, named by its own identifier rather than a date range alone, so
           the notes stay findable against the sprint backlog they discuss? Who was actually present, not
           who was invited?
     GOOD  "Sprint 24 (2026-06-08 to 2026-06-19). Facilitator: Priya Nair. Present: Priya Nair, Sam Osei,
           the full Developer group (4), Product Owner Dana Ruiz."
     WEAK  "Sprint retro, June." (no identifier a later reader can match against the sprint backlog, and no
           record of who actually spoke for the team)
     TRAP  Recording who was invited instead of who showed up. A retrospective's discussion is only as
           honest as the room that actually held it, and a later reader needs to know whose account this
           is. -->


**Sprint:** {{sprint_id}} ({{sprint_start_date}} to {{sprint_end_date}})
**Facilitator:** {{facilitator}}
**Present:** {{participants_present}}


## Previous Actions


<!-- WHAT  A check on the action items the previous retrospective produced: done, in progress, or dropped,
           with one line of why for anything not done.
     WHY   This section is this bundle's own contribution; no published vendor template carries it. It
           exists because unchecked action items from a previous retrospective are a named anti-pattern in
           the practitioner literature this research read, and because the Scrum Guide's 2020 rewrite
           downgraded the one mechanism that used to carry retrospective output forward: what the 2017
           Guide required, the current Guide only permits. Deep dive:
           sprint-retrospective-notes_companion.md section 3 (Anatomy > Previous Actions) and section 2
           (Origins and evolution).
     ASK   For every action item the previous retrospective produced, is its status recorded here: done,
           in progress, or dropped? Does every row that is not done carry one honest line on why?
     PRIORITY  List rows in the order the previous retrospective's Action Items table had them, so a
           reader can check this table against that one, line for line.
     ROW HINT  A good row names the action exactly as the previous retrospective wrote it, its status, and,
           if not done, one honest line on why.
     GOOD  | Add a staging smoke test before merge | Sam Osei | Done | Landed 2026-06-11, running on every
           merge to main. |
     WEAK  (a finished action left off the table entirely) (a finished action left off looks the same as
           one nobody tracked, and an unfinished one left off looks the same as one that never existed)
     TRAP  Silently dropping a row that was not finished instead of carrying it forward as "in progress" or
           "dropped, because...". An empty Previous Actions table, sprint after sprint, is usually not
           evidence the team has nothing outstanding. It is usually evidence nobody is reading this
           section, which is the exact failure it exists to catch. -->


| Action from previous retrospective | Owner | Status | Note |
|---|---|---|---|
| {{previous_action}} | {{previous_action_owner}} | {{previous_action_status}} | {{previous_action_note}} |


## What Went Well


<!-- WHAT  The team's own account of what worked in the sprint, and why it worked, not only that it did.
     WHY   "What went well" is the one phrase the Scrum Guide's own text supplies for the Sprint
           Retrospective's content, and every vendor template this research read carries a version of this
           heading. The "why" column exists because the largest study of retrospective content this
           research read found that the large majority of statements gave no justification at all. Deep
           dive: sprint-retrospective-notes_companion.md section 3 (Anatomy > What Went Well).
     ASK   Is each row a specific practice, not general morale? Does it say why the practice worked, not
           only that something went well?
     PRIORITY  No ranking; list rows in the order they came up in discussion.
     ROW HINT  A good row names a specific practice and the reason it helped, concrete enough that someone
           who was not in the room could repeat the practice on purpose next sprint.
     GOOD  | Pairing on the entitlement fix | Caught the edge case before it reached staging; a second set
           of eyes on the filter logic found the gap a solo review had missed twice. |
     WEAK  | Good week | (no practice named, no reason given, and nothing here is repeatable on purpose)
     TRAP  Writing one-word morale entries, "good," "solid sprint," instead of specific practices with a
           reason attached. A column that only asks what reproduces exactly the shallowness this bundle's
           own research measured. -->


| What went well | Why it worked |
|---|---|
| {{went_well_item}} | {{went_well_reason}} |


## What To Improve


<!-- WHAT  What the team says did not work, and at least one candidate idea for changing it.
     WHY   This section folds two headings vendor templates this research read publish separately, "what
           didn't go well" and "ideas for improvement", into one, so a named problem stays attached to a
           proposed change instead of floating unaddressed. Deep dive: sprint-retrospective-notes_companion.md
           section 3 (Anatomy > What To Improve).
     ASK   For every problem named, is there at least one candidate idea attached, even a rough one? Does
           the row say why the problem happened, not only that it did?
     PRIORITY  No ranking; list rows in the order they came up in discussion.
     ROW HINT  A good row names a specific problem and a concrete idea for changing it, not a diffuse
           complaint.
     GOOD  | Code review queue backed up for two days mid-sprint | One reviewer was out and nobody
           covered; rotate a designated backup reviewer into the on-call rotation. |
     WEAK  | Reviews are slow | (no cause named, no candidate idea attached; reads the same every sprint
           and nothing changes)
     TRAP  Naming a problem with nothing attached to it. A problem with no idea beside it tends to become
           an Action Items row with no substance behind it, or nothing at all. -->


| What did not work | Idea to change it |
|---|---|
| {{improve_item}} | {{improve_idea}} |


## Action Items


<!-- WHAT  The commitments this retrospective actually produces: what will change, who owns it, and by
           when.
     WHY   This renders the "Action Items" heading every vendor template this research read carries in
           some form, and it is the section the whole document exists to make binding: an unowned action
           item is the single most-named failure mode in the practitioner literature behind this bundle.
           Deep dive: sprint-retrospective-notes_companion.md section 3 (Anatomy > Action Items).
     ASK   Does every row have a named owner and a date? Is the change worth the retrospective time it
           took to identify, or is it small enough to cut rather than track?
     PRIORITY  List rows in the order the team intends to act on them.
     ROW HINT  A good row names the change as something that can be checked done or not, the owner, a
           person rather than a team, and a date.
     GOOD  | Add a designated backup reviewer to the on-call rotation | Dana Ruiz | 2026-06-26 |
     WEAK  | Improve code review | | (no owner, no date; an observation wearing an action item's clothing)
     TRAP  Writing an action item too small to be worth tracking, or one so large it will never be checked
           done. A commitment worth writing down should be able to justify the time this retrospective
           spent finding it. -->


| Action | Owner | Due |
|---|---|---|
| {{action_item}} | {{action_owner}} | {{action_due}} |

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 5 sections across 1 format(s), methodology Scrum/agile, typically owned by Scrum Master.