How does your team keep retrospective action items from disappearing?

[zoltanersek _outpostlabs_dev_]

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 _outpostlabs_dev_ !

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!

[zoltanersek _outpostlabs_dev_]

Thanks for sharing both examples, Olga. I like that they take very different approaches but have one thing in common: the review cadence.

I'm curious about the second team using Smart Checklist: have they found that keeping the action items as checklist items (rather than separate Jira issues) is enough to keep them visible over multiple sprints? Or do they ever get overlooked when the original work item is no longer active?

[Davit Mkrtchyan - Be On Time]

Hi @zoltanersek _outpostlabs_dev_ Zoltan -

It is funny how this is one of the most universal pains in any Scrum team.

Olga is spot on regarding the review rhythm. If you do not look at the items, they do not exist. But in my experience, there is a deeper reason why these items "quietly disappear" even when the team is committed and the tracking is in place.

The problem is that retro action items are usually treated as "invisible work."

Most teams plan their sprint capacity based on feature delivery and bug fixing. Then they add retro action items on top of that, as if they are free. But they are not. Every "process improvement" takes time away from a ticket.

When the pressure of the sprint goal hits, the "invisible work" is the first thing to be sacrificed because it is not a Jira ticket with a priority.

The only way I have found to truly stop the fade-away is to stop treating improvements as a side-activity and start treating them as a capacity allocation.

For example, explicitly reserving 5-10 percent of the team's bandwidth for "Continuous Improvement" as a non-negotiable part of the sprint. When a retro item becomes a planned allocation of time rather than a "wish list" item, it actually gets done.

Consistency in tracking is the map, but capacity is the fuel. Without the fuel, the map is useless.

Hope this perspective helps you and your team!

[zoltanersek _outpostlabs_dev_]

I like the distinction between tracking and capacity. I hadn't thought about it that way, but it makes sense that improvement work is often the first thing to be sacrificed when delivery pressure increases.

Do you reserve that 5–10% at the team level, or do you actually create and plan the improvement work as part of the sprint backlog?

[Davit Mkrtchyan - Be On Time]

Zoltan, glad that resonated. It is a shift in mindset that usually changes everything for a team.

To answer your question: the most effective way is a combination of both, but the order is critical.

First, you establish the capacity reservation at the team level. Think of it as a budget for the team. For example, if the team has 100 hours of total capacity, you consciously treat it as 90 hours for delivery and 10 hours for improvement.

Second, you absolutely create the improvement work as actual tickets in the sprint backlog. Why? Because if it is not a ticket, it is not real work. It has no owner, no definition of done, and no visibility.

The magic happens when the ticket is mapped to that reserved capacity. If a Product Owner tries to push a new urgent feature into those 10 hours, the conversation changes from "can we squeeze this in?" to "we are now consciously choosing to sacrifice our process improvement to hit this date."

That transparency is what stops the quiet disappearance of retro items. It makes the trade-off explicit rather than accidental.

Does your current process allow for that kind of explicit capacity split, or is everything currently fought over in the same backlog?

[zoltanersek _outpostlabs_dev_]

Thank you @Davit Mkrtchyan - Be On Time we did have 20% reserved for tech depts, keeping the lights on and other stuff like that. We might include retro action items there. We were already keeping the retro action items on a kanban board. 

[Davit Mkrtchyan - Be On Time]

Zoltan, reserving capacity for improvement work is exactly what keeps retro items from disappearing. Sounds like you already have a solid setup.