How does your team keep retrospective action items from disappearing?

[zoltanersek]

Our team has been talking about something that seems surprisingly common.

Retrospectives usually produce a handful of good action items, but a few sprints later many of them have quietly disappeared. Everyone agreed they were important, but once delivery work takes over, they often lose visibility.

I'm curious how other Jira teams handle this in practice.

• Do you create Jira issues for every retrospective action item?

• Do you keep them in your retro tool?

• Do you review old action items at the start of every retrospective?

• Do you assign an owner?

• Or do they usually fade away unless someone champions them?

I'm less interested in the "ideal" process and more interested in what actually happens on your team.

If you've found a workflow that consistently keeps retrospective improvements moving, I'd love to hear what it is, and what you've tried that didn't work.

[Olga Cheban _TitanApps_]

Hi there, @zoltanersek !

I can share what works for us and what another team in our organization does differently.

Example 1

We run our retrospectives in Confluence. Action items go at the end of the retro notes document, and yes, each item has a clear owner. We then review these items at the end of the next retrospective. If something hasn't been done, we talk about it. Sometimes the owner commits to finishing it within the next month, and sometimes we agree to deprioritize it. Not every action item stays relevant, and that's fine.

What this gives us is a simple, low-maintenance system. The retro document is the single source of truth. No extra tools, no separate boards. What is crucial is the review step - this is what keeps items from just fading away.

Example 2

Another team in our organization takes a different approach. They use our solution, Smart Checklist for Jira, to track retro action items directly inside a Jira work item. Smart Checklist lets you assign each item to a specific person, set deadlines, add details in expandable sections, and use custom statuses.

What this team likes about it is that they don't need to create separate tasks or subtasks for each action item. Everything lives in one checklist, and the progress is visible right on the work item. This is a lightweight solution that is easy to use. 

Both approaches work well. The key is to have a review rhythm that forces a clear decision: do it, reschedule it, or drop it.

I hope it's useful!