← All posts

Every retro ends with the same action items. Everyone agrees they need to be done, everyone nods, and two weeks later the same items are back on the board. So what’s wrong? Are they impossible to complete? Not really.

If your retrospective action items never get done, it’s almost never the retro that’s broken. The meeting worked. The follow-through didn’t. Below is why that happens, the four principles that fix it, and the one question you should be able to answer before you schedule another retrospective.

Why retro action items never get done

Most of the time it’s some mix of the following five failures.

• The action item has no owner. Guess what happens then. Nobody does it. “The team will look into it” means no one will.
• The action item has no due date. In that case it’s a wish, not an action item. If nothing is ever late, nothing is ever urgent.
• It lives outside the team’s workflow. If the item sits on a third-party retro board or a Confluence page, nobody opens it until the next retro.
• Nothing resurfaces it. Some retro apps let you re-import last meeting’s action items, but plenty have no way of bringing overdue items back on their own.
• There’s no accountability. Nobody is interested in — or ever actually looks at — how many retro action items the team closed.

Any one of these is enough to sink an action item. Most teams have all five.

How teams track retro action items today

You can get a surprising amount done in Jira natively. Most teams have a label or a board for retro action items and discuss them in every standup. Action items get owners that way, and they might even make it into a sprint.

Others use Confluence, with a page per retrospective recording what needs to be done.

But the most common setup is a third-party retro app. There are a ton of them and they all have broadly the same features, most of them letting you re-import last retro’s action items. Some will even create Jira tickets from them.

Plenty of teams use spreadsheets, which works fine for the most basic requirements.

All of these can work. What separates the ones that do from the ones that don’t isn’t the tool — it’s whether the four principles below are in place.

The one question: what’s your action item closure rate?

The title says to stop running retros until you can answer one question. It’s actually two: how many action items got resolved last month, and which action items keep coming back?

That’s your closure rate and your carryover rate. If you can’t answer both, you have no evidence your retros are changing anything, and the honest position is that they probably aren’t.

Four principles of effective retro action items

To be able to answer that question, you need four things to be true of every action item your team captures.

1. Every action item has an owner and a due date

Decided at capture, non-negotiable. One named person, not a lead who will “coordinate,” and a real date, usually before the next retro. If you can’t name an owner and a date while everyone is still in the room, the item isn’t ready to be an action item. Park it or drop it.

2. All open items are visible in one place

One list, one view, with overdue items highlighted. If the answer to “what’s still open?” requires opening three tools, nobody will ask the question.

3. Overdue items come back automatically

Not “we’ll remember to re-import them.” Something has to push an overdue action item back in front of its owner without a human deciding to go looking for it.

4. Someone or something tracks the closure rate over time

So you know whether you’re actually improving. The whole point of action items is making the team better — and you can’t tell whether you’re getting better if you never measure it.

Where Resurface fits

Resurface makes applying those four principles a no-brainer. It’s the follow-through layer that turns retro action items — captured by hand or by whatever third-party retro app you already use — into owned, due-dated, tracked Jira issues that keep resurfacing until they’re done.

It nudges the owner when an item goes overdue, counts every carried-over item so repeat offenders rise to the top, reports closure rate and average age on a dashboard, and runs entirely on Atlassian Forge, so your data never leaves Atlassian Cloud. It’s free for up to 10 users.

If you’d rather wire this up by hand first, we wrote a step-by-step guide to tracking retrospective action items in Jira with nothing but labels, JQL, and a dashboard. The principles are the same either way.

Frequently asked questions

Why do retro action items never get done?

Usually for five reasons: no owner, no due date, the item lives outside the team’s daily workflow, nothing resurfaces it when it goes overdue, and nobody tracks whether items get closed. Fix ownership and due dates first — those two alone account for most abandoned action items.

What is a good closure rate for retrospective action items?

A healthy team closes most of its action items within a sprint or two. The absolute number matters less than the trend: if your closure rate is falling or the same items keep carrying over, follow-through is breaking down and no change to the retro format will fix it.

How many action items should a retro produce?

Fewer than you think. Two or three items with named owners and real due dates beat ten that nobody has committed to. If you’re carrying items over every retro, you’re capturing more than the team can absorb.

Should retro action items live in Jira or in the retro tool?

In Jira, or wherever the team actually works. Keep the retro tool for the conversation, but the action item needs to end up in the system the team opens every day. Items that stay on the retro board are invisible between retros, which is exactly when they’re supposed to get done.

How do you hold people accountable for retro action items?

Give every item one named owner, make overdue items visible to the team, and review carryover out loud at the start of the next retro. Accountability comes from visibility, not from chasing — an item that resurfaces on its own doesn’t need a scrum master to nag anyone.

The short version

Before you book the next retro, try to answer the question: how many action items did the team close last month, and which ones keep coming back? If you can’t, the retro isn’t the thing to fix — the follow-through is.

Give every item an owner and a due date at capture, keep the open ones in one visible place, make the overdue ones come back on their own, and watch the closure rate. Do that and the same three items stop haunting your board.

Resurface does all four for you inside Jira, and it’s free for up to 10 users. It’s live on the Atlassian Marketplace, and the docs walk through capture, nudges, and the dashboards if you want the specifics first.