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?

[Olga Cheban _TitanApps_]

@zoltanersek _outpostlabs_dev_ it's a separate work item called Retrospective, and it's assigned to the team lead who moderates retro meetings. it's only closed when everything is either completed or transferred to the next Retro work item - pretty much like with any other task.

apart from that, each team member has their own dedicated tab where they can view all checklist items assigned to them (not only from the Retro action items, but in general). this also creates additional visibility directly in Jira. here's what it looks like:

[zoltanersek _outpostlabs_dev_]

I see, thanks for clarifying it 

[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.

[Nigel Budd]

I create work-items named process improvement or retro action and keep them on the backlog.

They can be refined, estimated, prioritised then bought into Sprints, there is often time consumed implementing improvements so it's fair to treat is as part of the scrum team delivery.

Dashboard reports to show how many of these improvement tickets have been dealt with over a period of time.

Simple, but it's a very transparent and effective solution.

[zoltanersek _outpostlabs_dev_]

that is an effective and easy solution, so, do you have issues with them disappearing with that setup? Are they usually picked up? Or passed over all the time?  or you kind of see them on the dashboard when needed? 

thanks 

[Nigel Budd]

They can easily be passed over of course, but by having them as tickets they won't disappear, you can measure how many are being dealt with, age of the tickets, and I hope that as part of each sprint planning session retro items would be considered for bringing into the sprint.

Jira provides visibility, the team have to play their part and see the benefit of continuous improvement, once you get started though and the benefits start being realised, then teams usually insist on wanting more.

[Luis Ortiz - Catapult Labs]

Hi Zoltan, this is a fantastic discussion. The "Retrospective Black Hole": where great ideas go to die a few sprints later. This is a universal pain point, trust me.

I completely agree with the points Davit and Nigel brought up. Davit’s concept of "invisible work" is also right; If an action item doesn't have capacity allocated to it, it will always lose out to feature delivery.

As a Marketplace Partner (co-founder at Catapult Labs), we spend our days building Agile ceremony apps natively inside Jira, so we see this exact dynamic constantly. The biggest reason action items disappear isn't a lack of team care; it's a disconnect in the tooling and workflow. When teams brainstorm in an external whiteboard or a separate document, the action items get trapped there. Out of sight, out of mind.

Here is the workflow we see consistently keep improvements moving:

• Rule of Two: Limit the outcome of the retro to a maximum of 1 or 2 action items. Any more, and focus is entirely diluted.

• Immediate Conversion: The retrospective meeting does not officially end until those 1-2 items are converted into actual, tracked Jira issues. (We built our Agile Retrospectives tool specifically so teams can click a sticky note and convert it to a Jira ticket instantly, but doing it manually works too!).

• Inject into the Active Sprint: Don't just send them to the bottom of the product backlog where they will age out. Put them directly into the active sprint alongside the feature work, with an assignee and an estimate.

If the continuous improvement work isn't sitting right next to the product code in the system of record, it almost always fades away.

When your teams use the Kanban board for retro items, do you find that developers pull those items into active sprints proactively, or do they still rely on the Scrum Master to champion them?

[zoltanersek _outpostlabs_dev_]

Thank you @Luis Ortiz - Catapult Labs I keep hearing this rule of two everywhere, I shall give it a try.