How to Run a Retrospective Action Item Review in English
Learn the English phrases for reviewing past retrospective action items: tracking follow-through, closing stale items, and reporting on progress.
Retrospectives that generate action items nobody revisits become a team’s least trusted ritual — the fix is a short, explicit review at the start of the next retro, and it needs its own vocabulary distinct from the retro’s usual “what went well” discussion. This guide covers the English for running that review.
Key Vocabulary
Action item review — the practice of opening a retrospective by revisiting items committed to in the previous session, before generating any new ones, to close the loop on past commitments. “Before we get into new topics, let’s spend five minutes on the action item review — three items from last time, let’s see where each one stands.”
Follow-through — whether a committed action item was actually completed, distinct from whether it was merely discussed or intended, the core thing a review is checking. “Follow-through on this one was good — the runbook update actually happened and it’s already been used during an incident.”
Stale item — an action item that has carried over across multiple retrospectives without progress, signaling either it wasn’t actually a priority or it lacked a clear owner. “This item has been carried over for three retros now — it’s officially stale. Either we commit to it properly this time with an owner and date, or we drop it.”
Owner (of an action item) — the specific named person responsible for driving an action item to completion, as opposed to a vaguely assigned team-level commitment. “Every action item needs an owner by name — ‘the team will look into it’ is how items become stale.”
Close (an item) — explicitly marking an action item as done, abandoned, or superseded, rather than letting it silently disappear from the list without acknowledgment. “Let’s formally close this one — it’s not that we forgot, it’s that the underlying problem got solved a different way when we migrated the service.”
Root-cause follow-up — checking not just whether an action item’s specific task was completed, but whether it actually addressed the underlying issue the retro identified. “The task itself is done, but as a root-cause follow-up, has it actually reduced the flaky test rate, or are we still seeing the same failures?”
Common Phrases
- “Let’s start with the action item review before we open up new topics.”
- “What’s the follow-through status on this one — done, in progress, or not started?”
- “This item’s been stale for a while — do we recommit with an owner and date, or close it?”
- “Who’s the owner on this one? It can’t stay assigned to ‘the team.’”
- “Even though the task is done, did it actually address the root cause we identified?”
Example Sentences
Opening a retrospective with an action item review: “Before new topics, quick action item review: the on-call handoff doc got updated, that one’s closed. The test flakiness investigation didn’t happen — let’s talk about whether it’s still a priority or should be dropped.”
Flagging a stale item: “This is the third retro where ‘improve deploy documentation’ has shown up without an owner — I’d rather we either assign it properly right now or take it off the list, since carrying it forward without action isn’t helping anyone.”
Closing an item that’s been superseded: “We can close this one — it’s not resolved in the way we originally planned, but the service migration made the original problem moot, so there’s nothing left to act on.”
Professional Tips
- Start every retrospective with the action item review, not buried at the end — items reviewed last get rushed or skipped entirely when time runs short.
- Report follow-through honestly, including “not started,” rather than softening it — a team that can’t say an item didn’t happen loses the ability to trust its own retro process.
- Name a stale item explicitly rather than letting it silently roll forward again — calling it out is what forces a real decision between recommitting and closing it.
- Always assign a specific owner to any item that survives the review — an item without a named owner is functionally guaranteed to become stale again.
Practice Exercise
- Write an opening line for an action item review at the start of a retrospective.
- Write a sentence flagging a stale item and proposing either recommitment or closure.
- Write a sentence closing an action item that was superseded by another change.
Navigating Nuances: Refining Your Retrospective Language
Running a successful retrospective isn’t just about identifying problems; it’s fundamentally about communication. And when you’re learning professional English, even seemingly straightforward discussions around action items can be tricky. The key is to move beyond simply stating what needs doing and instead focus on expressing your understanding of the situation, tracking progress, and collaboratively driving solutions. Let’s look at how to refine your language in a few common scenarios.
One frequent issue is when an action item hasn’t been addressed. Instead of saying something blunt like “This wasn’t done,” which can feel accusatory, try framing it with curiosity and a focus on understanding. For example, during a team check-in, you could say: “I noticed the ‘Document API Usage’ action item from our last retrospective hasn’t been completed. Could you walk me through what happened there? Were there any roadblocks we can address now to help move things forward?” This phrasing demonstrates your awareness of the issue and invites a collaborative discussion about why it stalled. Similarly, in a pull request comment, instead of saying “Fix this!” you could write: “Regarding the ‘Update README’ action item, I’m wondering if we can revisit this to ensure clarity for new contributors. Perhaps we could schedule a quick sync to discuss?”
Another common situation is identifying items that have become stale. It’s important to acknowledge these without immediately dismissing them. A good approach involves phrasing like: “Let’s circle back on the ‘Investigate Performance Bottlenecks’ action item from the retrospective. It’s been a few weeks, and I wanted to check if we still see this as a priority or if the context has changed.” This acknowledges the passage of time while politely prompting a re-evaluation. You can also use phrases like “Let’s flag this for review” – it’s a clear signal that something needs attention without placing blame.
Finally, when reporting on progress, avoid vague statements like “We’re making progress.” Be specific! Instead of saying: “The action items are moving along,” try “We completed 3 out of the 5 action items from the last retrospective – specifically, we finalized the design for the new user interface and drafted the initial documentation. We’re currently working on implementing the changes in the codebase.” This level of detail demonstrates accountability and provides valuable information to the team. Remember, clarity is paramount when communicating about progress, particularly within a diverse group of developers with varying levels of English proficiency.