Free Standup Retrospective Template

A standup retrospective is a structured look at whether the standup itself is working. Not the team's work, not the sprint — the standup. Most teams adopted standup ten years ago and never re-evaluated it. The result is a daily meeting that is sometimes useful, often performative, and always taken for granted. The retrospective is the way to find out which one yours is.

The template below is short on purpose. A standup retrospective is a forty-five minute exercise, not a half-day workshop. It produces one of three outcomes: keep, change, or kill. Each outcome is valid; the point is to make the choice deliberately rather than continuing standup by inertia.

When to use it

• You have not asked "is standup working?" in over six months.
• Standup has become a status update for the manager, not coordination for the team.
• Engineers visibly tune out during standup or arrive late by default.
• The team has gone async or distributed and the original standup format has not adapted.
• A new manager is starting and inheriting the standup as it is.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

STANDUP RETROSPECTIVE — [team]
Date:       [date]
Facilitator: [name]
Time-box:   45 minutes
Outcome:    [keep / change / kill]

PART 1 — INVENTORY (10 min)
  Current standup format:
    Frequency:   [daily / 3x/week / etc.]
    Mode:        [sync video / sync in-person / async written / hybrid]
    Duration:    [actual average, not scheduled]
    Attendance:  [usually N of M]
    Who runs it: [name / round robin / nobody]

PART 2 — WHAT IT IS FOR (10 min)
  What were we hoping standup would do for us?
    [ ] Surface blockers in time to act on them
    [ ] Coordinate handoffs across timezones
    [ ] Build a sense of team / connection
    [ ] Give the manager visibility
    [ ] Force daily reflection on progress
    [ ] Habit / ritual
    [ ] Other: [...]

  Which of these is the standup actually doing?
    Working:    [list]
    Not working: [list]
    Could be done better another way: [list]

PART 3 — COSTS (5 min)
  Engineering minutes per week:
    [N people] x [duration] x [days] = [total minutes/week]
    Annual cost (rough): [N hours / year]
  Less visible costs:
    - Performance pressure (engineers performing for the meeting)
    - Context-switching cost at standup time
    - Asymmetric cost across time zones

PART 4 — OPTIONS (15 min)
  Discuss explicitly. Pick one:

  A. KEEP — standup is working. Confirm format. Next review in 6 mo.

  B. CHANGE — pick a change to try for the next [4 weeks]:
       [ ] Move to async written
       [ ] Reduce frequency (e.g., daily → 3x/week)
       [ ] Shorten and stick to it
       [ ] Restructure questions to focus on blockers
       [ ] Rotate facilitation
       [ ] Move to handoff-only model
       Other: [...]

  C. KILL — replace standup with [alternative]:
       Pick one:
         [ ] Written wraps / EOD handoffs
         [ ] Blocker channel that engineers post in as needed
         [ ] Weekly sync only
         [ ] On-demand only
       Confirm coverage of the original goals.

PART 5 — DECISION & FOLLOW-UP (5 min)
  Decision:                [keep / change / kill — with detail]
  Trial period (if change): [N weeks]
  Next retro to evaluate:  [date]
  Owner:                   [name]
  How will we know it worked?
    - [signal]
    - [signal]

How to use it well

• "Kill" is a real option, not a strawman. Many teams discover during this exercise that what their standup was for is now better served by written wraps and a blocker channel. Killing standup is the right move for those teams. Treating "kill" as a fake option leads to half-hearted "change" outcomes.
• Cost in minutes-per-week, not minutes-per-meeting. The fifteen-minute meeting is sixty minutes a week per engineer, plus context switches. Stating the annual cost in hours per year makes the conversation honest.
• "What were we hoping for" is the framing question. Most teams cannot answer this cleanly, and discovering they cannot answer it is half the value of the retro. A meeting whose purpose nobody can articulate is rarely worth keeping unchanged.
• Pick one change, not three. Teams that change standup in three ways at once cannot tell which change worked. Try one thing for four weeks; evaluate.
• Set the next retro date in the room. Without a follow-up review, the team drifts back to whatever standup is least friction. The follow-up retro is the forcing function.

What to skip

Skip the retro framework debate. Whether you call this a retrospective or a process review or a postmortem of meetings does not matter. The template above is the format; the framework label is decoration.

Skip running this retro at the same time as a sprint retro. Mixing the two produces a long meeting where the urgent topics (sprint) crowd out the structural topics (standup). Schedule them separately.

Frequently asked questions

Is this template free?

Yes. The structure above is the template. Run it as a 45-minute team meeting with a shared Notion page open.

Can I edit it?

Yes. Common edits: add a section for hybrid in-office/remote teams, or a section for cross-team standups if your team participates in more than one.

Do I need to give my email?

Not for the template. The download is just a polished Notion version; the email is only for our newsletter list.