A retrospective action item is a specific improvement the team agrees to try after a retrospective. A useful action names one owner, describes the change, sets a review date, and identifies evidence that will show whether it helped. “Communicate better” is a goal; “trial a blocker check at 10 a.m. for one sprint” is an action.
Updated September 11, 2026. Added six worked examples, a copyable action register, an outcome check, and a review agenda. The examples below are illustrative, not measured customer results.
Why action items get forgotten
An action can disappear because nobody owns it, there is no time to do it, or the team never agrees what completion means. A long list adds competition with sprint work. A document that nobody reopens makes the commitment invisible.
The fix is to make the improvement small enough to attempt and visible enough to review. Start with one to three actions as a facilitation guideline, not a universal limit. If the team has capacity for only one, choose one.
The Scrum Guide says the Sprint Retrospective plans ways to increase quality and effectiveness, and that the most impactful improvements should be addressed as soon as possible. It does not prescribe a three-action rule or a particular tracking tool.
How to write a retrospective action item
Use this format:
[Owner] will [specific change] by [date]. We will review [evidence] on [review date] and decide whether to keep, adapt, or stop it.
An owner coordinates the work and reports the result. They do not have to do every task themselves. Before accepting the action, confirm that the owner has the authority, time, and support to attempt it.
Tie the action to an observation: what happened, in what situation, and why it mattered. Then choose the smallest change that could address it. Avoid assigning a tool purchase or a large reorganization when a short experiment can test the underlying assumption.
Six retrospective action-item examples
| Vague suggestion | A reviewable experiment | Evidence to review |
|---|---|---|
| Improve code reviews | Alex coordinates a daily 15-minute review slot for one sprint | Age of waiting pull requests and whether the slot caused interruptions |
| Communicate blockers earlier | Maria trials a 10 a.m. blocker check for one sprint, with one named person helping each blocked item | Which blockers were raised earlier and which still waited |
| Stop scope creep | Priya asks the PM to record each mid-sprint addition and the work it displaces | Additions with an explicit trade-off versus unplanned additions |
| Improve on-call handovers | Sam creates a short handover checklist by Friday and tests it for the next two handovers | Missing context reported by the incoming engineer |
| Reduce meeting load | Devon pauses one recurring status meeting for two weeks and provides a written update | Missed decisions, questions, and time participants say they recovered |
| Make release checks consistent | Lee adds a rollback-check step to the next release checklist | Whether the next release has a documented rollback owner and procedure |
These are starting points. Agree on a baseline and an attainable success condition with your team. A two-week change in one metric does not prove causation; combine the numbers with what people observed.
Copyable retrospective action-items template
Copy this register into a shared document or your normal work tracker:
| Problem observed | Experiment | Owner | Due date | Review date | Success evidence | Status | Decision |
|---|---|---|---|---|---|---|---|
| Reviews waited until the sprint's last day | Trial a daily review slot | Alex | Agree before next sprint | Next retro | Review wait time plus team feedback | Planned | Pending |
| Context missing at on-call handover | Test a five-point handover checklist | Sam | Friday | After two handovers | Missing handover details | In progress | Pending |
| Add your observation | Define one small change | Name one person | Set a date | Set a review date | Say how you will check | Planned | Pending |
The action item builder fills this row in from six questions and flags a goal, a missing owner, or missing evidence before you commit to it. It runs in your browser and stores nothing.
The example rows deliberately use relative dates. Replace them with actual calendar dates before committing. Link the register from the place the team already checks; maintaining a second invisible backlog defeats the purpose.
Review the last actions before collecting new feedback
Reserve the first five minutes of the next retrospective for follow-up. This is a suggested timebox; extend it when an important experiment needs more discussion.
- Owner's update: What did we try? What did we fail to try?
- Evidence: What changed, and what else might explain the change?
- Decision: Keep the change, adapt it, or stop it deliberately.
- Next step: If more work is needed, agree on capacity, ownership, and a new review date.
Use statuses such as Planned, In progress, Done, Blocked, and Stopped. Keep the outcome decision separate from the task status: creating a checklist can be Done even when the experiment showed that the checklist did not help.
What to do when an action keeps carrying over
Do not copy the same overdue sentence into another retro without discussing the reason. Ask whether the work is too large, outside the owner's control, no longer useful, or missing capacity.
Break it into a smaller test when possible. Escalate a dependency to the person who can resolve it. Stop an action that no longer matters and record why. If the team still wants the change, make room for it instead of treating it as unpaid work around the sprint.
How NextRetro fits the follow-up process
Run collection, grouping, voting, and discussion on a free retrospective board, which opens the board-name dialog directly. Capture the agreed improvement and export the outcome to the team's usual work system. Participants can join without accounts, and the homepage supports guest board creation.
According to current pricing, Free includes recent history and PDF or Markdown export. Pro includes full retro history, team workspaces, and creating the next board from a previous retro. Choose the option that makes the previous action easy to find; a shared register is a valid starting point.
Frequently asked questions
How many action items should a retrospective produce?
Start with one to three, based on capacity. One well-owned experiment is a useful outcome. There is no universal rule requiring three actions, and a larger count is not evidence of a better meeting.
Who owns retrospective action items?
Name one person to coordinate each action. The team can share the work, but a named owner makes the next step and update clear. The facilitator should not automatically own every improvement.
How do you measure whether an action helped?
Decide what to observe before the experiment starts. Compare the result with the previous situation, ask about side effects, and record whether to keep, adapt, or stop the change. Task completion alone does not establish improvement.
Should actions go in the sprint backlog?
When an improvement needs implementation work, discuss it in sprint planning and make it visible in the team's work system. The Scrum Guide allows the most impactful improvements to be added to the next Sprint Backlog; it does not require every retro note to become a backlog item.
For help starting the session, see our no-participant-signup guide. If you are evaluating tools, compare free-plan and history limits before deciding where the action register will live.
