Retrospective action items: a template for the next sprint

A retrospective action item needs an agreed change, one owner, evidence of completion, and a scheduled review. Write those down before the team leaves. At the review, check whether the change happened and whether it helped. Those are separate questions.

This workflow is for facilitators whose teams already run retrospectives and keep returning to unfinished improvements. If you need the meeting agenda or a format, start with the sprint retrospective guide.

Copy this retrospective action item template

Use one record per agreed experiment. Keep it somewhere the team can open during planning and at the next retrospective.

Observation:
  [Event + example]
Action:
  [Change to try next sprint]
Owner:
  [Named coordinator]
Complete when:
  [Checkable evidence]
Outcome to inspect:
  [Effect + evidence]
Target date:
  [Ready / trial end]
Review:
  [Date + meeting]
Status:
  [Pending / In Progress /
   Done / Not Done]
Next decision:
  [Keep / revise /
   carry forward /
   escalate / stop]

The completion criterion should be checkable by a teammate. "Improve code review" leaves too much open. "Publish a first-review rota and use it on two eligible pull requests" gives the team something to inspect.

The outcome is the reason for trying the change. A rota can exist and still leave pull requests waiting. Keep the completion evidence and the outcome observation in the same record so the review covers both.

These fields and the cadence below are practical recommendations. The Scrum Guide says the team should address its most impactful improvements as soon as possible and may add them to the next Sprint Backlog. [1]

A worked example: pull requests waiting for a first review

Suppose a team finishes a retrospective with "get reviews moving sooner." Before accepting that action, ask for an example of the delay and agree on a change the team controls.

The following record is illustrative; it describes a proposed experiment, with no claimed customer results.

Avery coordinates the experiment. Reviewers still need to agree to the work, and the team needs to decide how much review time to reserve in the sprint.

The two-PR check establishes that the team tried the rota. Such a small sample gives limited evidence of its effect. If no eligible PRs arrive, record that the trial had insufficient exposure and decide whether another sprint is worth it.

Carry the work into sprint planning

Bring the action record to planning while the team decides what it can take on. The Sprint Backlog is a plan by and for the Developers, so discuss the improvement work with the people who will do it. [1]

For the review-rota example:

1. Avery confirms that someone will publish the rota before it is needed.
2. Reviewers agree on coverage and flag absences or existing support duties.
3. The team includes the work in its plan and reduces other commitments if necessary.
4. The facilitator adds the evidence review to the next retro agenda.

Start with one improvement the team can try. If an action needs a substantial tooling change, make that work visible during planning.

Review progress before the next retrospective

Choose a checkpoint early enough to fix a blocked experiment. Halfway through the sprint is a useful starting point for the example above. A change needed before planning needs an earlier check.

Ask the owner what has happened, what is blocked, and what help is needed. Keep a short note beside the action. If the team changes the scope or target date, preserve the original agreement and record the reason.

At the next retrospective, open the previous actions before collecting new ones. Atlassian's retrospective play identifies building an action plan and following up in future meetings as part of continuous improvement. [2]

For each action, inspect the completion evidence first. Then discuss the outcome and choose the next decision:

Avoid repeatedly moving a due date without discussing why the action stalled. A smaller experiment, a capacity decision, or an escalation may be needed. Keep stopped actions in the review notes so the same suggestion can be evaluated against what the team already learned.

Use ScrumDeck to keep the review connected

ScrumDeck's retrospective workflow lets the facilitator capture action text and assign a participant. Put the completion criterion and review date in the action text, with a link or reference to longer evidence where needed. The action entry is limited to 300 characters, so keep the full template in your team's shared notes if it needs more room.

For the example above, a compact entry is:

Trial a first-review rota in Sprint 19. Complete when the rota is linked and used on two eligible PRs. Inspect review wait and interruptions at the Sprint 19 retro. Evidence: team review notes.

Assign Avery in the participant selector. Between meetings, use the account's action-items dashboard to edit the action text and update its status.

When you create another retrospective for the same account, ScrumDeck links the account's previous completed retro. During brainstorming, the facilitator can review its actions and mark them Done, In Progress, or Not Done.

If the account runs several teams' retros, check which previous session is linked before treating it as your team's follow-up list. Use the account action-items dashboard to check older commitments too.

Retrospectives are included in the paid Starter and Professional plans; free planning rooms do not include retrospectives. Retro retention is 30 days on Starter and 90 days on Professional. Keep a separate record for evidence or decisions you need beyond that period.

Explore ScrumDeck's action-item workflow, then compare plans and limits if your team needs a shared place to capture owners and review previous commitments.

Sources

[1] The Scrum Guide

[2] Sprint Retrospectives — Atlassian Team Playbook