Action Items That Actually Get Done

Every team has run this experiment, usually without meaning to. A retro ends with six action items and everyone nodding. Two weeks later, the next retro opens, someone asks "did we do the things?", and the room goes quiet. One item got done because someone happened to care. Two are half-remembered. Three are gone entirely. Then the team generates six new action items and repeats the cycle.

This failure is so common that many experienced people have quietly concluded action items are theater — a ritual of writing things down so the meeting feels productive. They're wrong about the concept but right about the usual execution. Action items fail for specific, fixable reasons, and teams that fix them get a compounding advantage: retros that change things, meetings that produce work instead of vibes, and a reputation — internally and with stakeholders — for doing what they said. This post is the full system: how items die, how to capture them so they can live, and how to build the review loop that makes follow-through the default instead of the exception.

The five ways action items die

Watch a dead action item's lifecycle in reverse and you'll find one of five causes of death. The system later in this post exists to block each one.

1. It was never really captured. "We should improve our deploy docs" gets said, heads nod, and nothing is written — or it's written in a notes doc nobody reopens. Spoken agreement is not capture. Capture in a location that will never be looked at again is also not capture.

2. It was assigned to everyone. "The team will keep an eye on flaky tests." An item owned by everyone is owned by no one; each person reasonably assumes someone else has it. This is diffusion of responsibility, the same effect studied in bystander research, and it operates just as reliably in a sprint team as on a street corner.

3. It had no deadline — or a fake one. No date means "someday," and someday loses to every dated task, forever. A fake date — one picked to end the discussion, with no relationship to anyone's actual capacity — is worse, because it trains the team that dates on action items are decorative.

4. It was too big to be an action. "Improve onboarding" is a project wearing an action item's clothes. Nobody can do it in a sitting, so nobody starts, and it rolls forward until everyone is tired of seeing it and it's quietly dropped.

5. Nobody ever asked about it again. This is the big one — the cause behind the causes. If items are never reviewed, then capture quality, ownership, and deadlines all stop mattering, because the team learns the real rule: nothing happens if you don't do it. Follow-through isn't a property of items. It's a property of the loop around them.

Capture: the standard for a well-formed item

Fix capture first, because malformed items can't be saved by any amount of tracking. A well-formed action item has four fields, and it isn't done being written until all four exist:

Field	Standard	Bad example	Good example
Action	Starts with a verb; completable in one sitting or clearly scoped	"Deploy docs"	"Rewrite the deploy runbook's rollback section"
Owner	Exactly one name	"Frontend folks"	"Priya"
Due date	A real date the owner said out loud	"Soon" / blank	"June 20"
Done-when	An observable state, one line	"Better docs"	"Runbook updated; link posted in #eng"

The done-when field is the one most teams skip and the one that pays best. It forces scope agreement at capture time — the cheapest possible moment — instead of at review time, when "I thought you just meant the rollback part" turns into a five-minute renegotiation. It also makes "done" checkable by anyone, not just the owner.

Two capture rules for the meeting itself:

Write items live, on a shared screen. Not in someone's private notes to be "cleaned up later" — later-cleanup is where items go to die, and private notes hide the malformed fields. When the item goes up on screen with an empty Owner field, the silence does the work: everyone can see it's unowned, and the facilitator can ask directly.

Get verbal acceptance, not assignment. "Priya, can you take this by the 20th?" and wait for the yes. An owner who accepted out loud in front of the team is in a completely different psychological position than one who found their name in the notes afterward. Commitments made publicly and voluntarily are the ones people move deadlines to keep — this is one of the most consistently replicated findings in commitment research. If the person hesitates, that's not friction, that's information: the date is wrong, the scope is wrong, or the owner is wrong. Fix it now, in the thirty seconds it takes, instead of discovering it in two weeks.

The one-sitting test and the project boundary

Before an item is accepted, apply the one-sitting test: can the owner plausibly do this in a single focused block — two hours or less? If yes, it's an action item. If no, you have two honest options:

• Slice it. "Improve onboarding" becomes "Draft the first-week checklist and share it for comments." The rest of the project stays in the discussion notes as context, not as a phantom commitment.
• Promote it. Some retro outcomes genuinely are projects. Then the action item is: "Ravi: write a one-page proposal for onboarding overhaul and get it on the roadmap review agenda by July 1." The proposal is the action; the project gets planned through your normal planning process, not smuggled in through a retro.

Teams that enforce this boundary stop generating the zombie items that roll from retro to retro for a quarter, and their action lists get shorter and more honest — which brings up quantity.

Fewer items, chosen deliberately

Here's a pattern worth stealing from teams with high follow-through: they leave meetings with fewer action items than teams with low follow-through. Three items done beats eight items abandoned — not just in output, but in what it teaches the team about whether commitments here are real.

Practical cap: a retro produces at most three action items; a working meeting, at most one per attendee. When a retro discussion surfaces ten worthy ideas, dot-vote and take the top three. Say the quiet part out loud: "The other seven are real, and we're not committing to them, because we'd rather finish three than gesture at ten." Ideas you declined to commit to can be parked in a visible backlog column — see below — where they can be promoted at a future retro if they keep mattering. Most won't keep mattering, which is exactly the point: the parking lot is where you find out which problems were real and which were just vivid that day.

Capacity math makes the cap concrete. If action items are done in the margins of normal work, a person has maybe one to two hours a week of margin. An item scoped to a two-hour sitting means each person can genuinely carry one, maybe two open items at a time. Assign a third and you're not adding output — you're choosing which existing item silently dies.

Give items a home: the tracking board

Meeting notes are where action items are born; they are a terrible place for them to live. Notes are organized by meeting date, so answering "what's open and who owns it?" means archaeology across six documents. Items need a single home organized by state, not by origin.

A lightweight board with four columns does it:

• Parked — ideas the team declined to commit to; reviewed occasionally, deleted freely
• Committed — accepted items with owner, date, and done-when
• In progress — the owner has started
• Done — kept visible for at least one review cycle before archiving, because seeing the Done column fill up is half the motivation system

Every action item from every ritual — retros, planning, 1:1s, incident reviews — goes on the same board. One home, not one board per meeting series, or you've just recreated the archaeology problem with extra steps. Cards carry the four fields plus a link back to the source discussion for context.

In Openbook, teams typically run this as a Table Board or Kanban Board room in the team's space — Openbook's retro rooms can also export their action items directly, so the capture-to-board step doesn't depend on anyone's memory. But the tool matters far less than the properties: one board, visible to everyone, organized by state, with owners and dates on every card. A shared spreadsheet meeting that standard beats a fancy tool that doesn't.

One anti-pattern to name: the private tracker. When the team lead keeps the action list in their own notes and chases people individually, follow-through becomes surveillance — the lead is the only one who knows the state, so the lead does all the pushing, and everyone else's relationship to commitments becomes "wait to be nagged." A public board inverts this: state is ambient, and the social force comes from visibility rather than from one person's persistence. This is the difference between accountability and micromanagement, a distinction we dig into in Accountability Without Micromanagement.

The review loop: where follow-through actually lives

Everything above is preparation for this section. The single highest-impact change — worth more than perfect capture, worth more than any tool — is this rule:

Every recurring ritual opens with a review of the action items from the previous one. First agenda item. Every time. No exceptions.

Retro opens with last retro's items. Weekly sync opens with last week's items. 1:1 opens with the commitments from the last 1:1. The review is short — for three items it's under four minutes — and it follows a fixed script per item:

Facilitator: "First item: rewrite the rollback runbook — Priya, due the 20th. Where does it stand?" Owner, one of three honest answers: "Done — link's in #eng." → Move to Done. Brief acknowledgment. Next. "In progress — I need until the 27th." → Update the date once. Next. "Not started, and honestly it won't happen — the migration ate my week." → Drop it or re-own it. Next.

Three rules keep the script working:

Status, not story. The review is not a discussion slot. If an item needs real conversation — scope changed, blocked on another team — it gets 30 seconds to become an agenda topic later in the meeting, and the review moves on. Reviews that balloon into discussions get skipped the following week "to save time," and the loop dies.

One renewal, then a decision. An item can have its date moved once. The second time it slips, the fixed choices are: drop it explicitly, re-scope it smaller, or hand it to a new owner. What's forbidden is the third silent rollover — that's how boards fill with zombie items, and a board with zombies teaches everyone that the board is fiction.

Dropping is legitimate. "We chose not to do this and we're saying so" is a perfectly good outcome — strictly better than the item rotting in Committed. Some teams keep a one-line log of dropped items with reasons; patterns in that log ("we keep dropping documentation items") are themselves retro material.

The tone of the review determines whether people are honest in it. "Not started" answered plainly and met with "okay — drop it or re-date it?" produces a team that reports real status. "Not started" met with visible disappointment produces a team that says "almost done" for three consecutive weeks. You are training people every single review; train for honesty, not for performed progress.

Deadlines that mean something

A few mechanics that separate real dates from decorative ones:

The owner sets the date. Not the facilitator, not the loudest person in the room. "When can you have this by?" produces dates people defend. "Can you do it by Friday?" produces dates people apologize about. The difference is authorship.

Dates land before the next review — usually. For a biweekly retro, items due within the two-week window mean every item gets reviewed exactly once and nothing has time to fade. An item that genuinely needs four weeks is fine, but say so at capture and expect two reviews to touch it.

Reminders are infrastructure, not nagging. A board with due dates should notify the owner as the date approaches — most tools do this natively. The point is to move the memory burden off humans entirely. "I forgot" is a system failure, and it has a system fix.

Watch for the chronic yes. If one person's items slip every cycle, the review script will surface it — but the fix happens in the 1:1, not in the group review. Usually the diagnosis is over-commitment (they accept everything), invisible workload, or items that keep landing on them because they're capable. All three are management problems wearing an action-item costume; the board just made them visible, which is the board doing its job.

Special cases worth handling on purpose

Cross-team items. "Marketing will send us the assets" is not an action item you can hold a retro over — nobody in your ritual owns it. Convert it: the item your team owns is "Sam: get a committed date from marketing and put it on the board by Thursday." Own the pursuit, since you can't own the delivery. If cross-team dependencies dominate your action lists, that's a bigger coordination problem than a board can fix — Managing Dependencies Before They Manage You covers that territory.

Incident and post-mortem items. These deserve stricter treatment than retro items, because the cost of dropping them is a repeat incident. Same board, but tagged, with a hard rule: post-mortem items can't be dropped in the normal review — they can only be closed done, or escalated to whoever owns reliability. If they age past 30 days, they appear in a report someone senior reads.

Items from 1:1s. These are commitments between two people, and they belong in a shared 1:1 note rather than the team board — but the same loop applies: the next 1:1 opens with them. A manager who reviews their own commitments to their report ("I said I'd talk to finance about the conference budget — I did, here's the answer") is doing more for team follow-through culture than any process rollout, because everyone calibrates against what leaders actually do.

Recurring "action items." If the same action shows up every cycle — "post the release notes," "update the customer list" — it's not an action item, it's an operational task. Move it to a recurring checklist or an ops board with a real cadence. Action boards are for one-time commitments; letting routine work camp there buries the real items.

Diagnosing your current system: a quick audit

Before rolling anything out, measure where you are. Pull up your last three retros or team meetings and score them:

1. Can you find the action items from each meeting in under two minutes? (If not: capture/home problem.)
2. Does every item have a single named owner and a date? (If not: formation problem.)
3. What fraction of items reached a definitive end state — done or explicitly dropped — before the next meeting? (This is your closure rate, the one metric worth tracking over time.)
4. Were previous items reviewed aloud at the next meeting? (If not: loop problem — fix this one first.)

Most teams that feel bad about follow-through discover a closure rate around 20–30% and no review loop. Teams running the full system reliably sit above 80% — not because the people changed, but because unfinished items stopped being invisible. Track closure rate for a quarter and put it where the team can see it; watching it climb from 25% to 80% is its own reward system.

What a healthy board looks like after a month

Concreteness check: here is roughly what the board of an eight-person team running this system looks like four weeks in.

Column	Count	What's in it
Parked	5	Retro ideas the team declined; two will be deleted at the next review
Committed	4	All with owner, date, done-when; oldest is 9 days old
In progress	3	One has had its single date renewal
Done	11	Kept visible; archived after the next retro opens

Read the health signals from the shape, not the contents. Committed plus In progress stays in single digits — roughly one open item per person, which matches the margin math from earlier. Nothing in Committed is older than one review cycle without a decision on record. Done is the biggest column, which is what makes the review a thirty-second morale event instead of a guilt ritual. And Parked shrinks as often as it grows, because parking is a deferral, not a burial.

The unhealthy shapes are just as recognizable: fifteen cards in Committed with no dates means capture theater; an empty Done column with a growing In progress column means items are too big — re-read the one-sitting test; a Parked column with forty cards means the team is using the board as a wish list and nobody has deleted anything since it launched.

Rolling it out: your next steps

Don't announce a grand new process. Install the system in this order, one piece per week, starting with the piece that carries the others:

1. This week — start the loop. At your next recurring meeting, open with a review of whatever action items you can reconstruct from last time, even if the list is embarrassing. Say the new rule out loud: "From now on, we start every one of these by walking the open items."
2. Next week — fix capture. Write items live on a shared screen with all four fields: verb-first action, one owner, owner-chosen date, done-when. Get verbal acceptance for each.
3. Week three — give items a home. Stand up the four-column board, migrate open items onto it, and link it from every meeting agenda. Turn on due-date notifications.
4. Week four — install the caps and rules. Three items per retro, the one-sitting test, one renewal then a decision, dropping is legitimate.

If you want the home ready-made: an Openbook space gives you a Kanban or Table Board for the action board, Retrospective rooms that capture and export action items with owners, and notifications that chase due dates so no human has to. Start free at /pricing — then let your next retro be the one where "did we do the things?" gets a boring answer: yes, mostly, and here's the board.