After a Retro we usually have 2 or 3 Actions to address in the next Sprint. Some of these Actions are sometimes more of a reminder to Developers.
Who do we ensure they are addressed in Sprint?
We're using TFS as the ALM tool. We do view a Kanban Board at each day's Standup.
Retrospective actions are a vital part of the Sprint work, so they should be agreed with PO and tracked as such.
You mentioned you use a Kanban board. Why not tracking each action as an item in the board? You may want to have a mean to separate these items from the other Stories, but it all boils down to what works better for you.
In our team, we use a specific swimlane for team goals. On these goals, we have both the actions from the retrospective alongside the goals the team agreed to deliver at the end of the sprint. That's one way amongst several other similar organizations.
Bottomline: The Actions should be visible to the team on the team board. The best way for a team to make it real depends entirely on the team itself, exploring and experimenting different approaches.
A Sprint Retrospective is part of the inspect-and-adapt process. The 2020 Scrum Guide says that "[t]he most impactful improvements are addressed as soon as possible," but doesn't prescribe how the team must implement any given adaptation.
The whole Scrum Team is collectively responsible for working together to decide how to best implement needed changes. If the team isn't doing that, it's not being self-managing. If the Scrum Master isn't facilitating the team's self-management of its own continuous improvement process, then the role's accountability for "[c]oaching the team members in self-management" isn't being effectively performed.
Since the whole Scrum Team is collectively responsible for managing its own continuous process improvement, when in doubt ask the team how they plan to implement and evaluate the adaptation. Without a team-driven plan to both institute and validate proposed changes, there's likely insufficient buy-in or commitment to bother tracking them.
As a practical matter, items from a Sprint Retrospective tend to fall into a few broad categories. Process changes should be implemented as soon as possible through the appropriate team process or artifact. Examples include:
- Updates to the Definition of Done.
- Changes to the way Sprint Backlog Items are handled.
- Modifications of the team's information radiators (e.g. Kanban board or story cards).
- Other adaptations to the Scrum Team's processes, artifacts, and events.
Retrospective items aren't usually "work" in the sense that they're first-class items to be tracked on the Product Backlog, but there are always exceptions. If you have such an item, such as "Embiggen the Team Frobnosticator," then you should certainly have worked with the Product Owner to add that to the Product Backlog already.
The rest of the items are things the Scrum Team should collaboratively be handled directly. For example, trivial updates to the Definition of Done should just get handled, so that the team can immediately take those changes on board. Non-trivial changes related to the Product Goal that include measurable work should be on the Product Backlog. However, when the work is more of a chore or task, it belongs on the Sprint Backlog as a work item instead.
Measurable action items belong in one of Scrum's defined artifacts. Less-measurable items (e.g. adaptations to the way the Daily Scrum is implemented or facilitated) should either be decomposed into measurable actions, or part of the empirical control process. In the latter case, empirical control may be as simple as asking the team at defined intervals or at the next retrospective whether they think X has improved.
In most cases, the Scrum Team should be coming out of each Sprint Retrospective with something actionable and measurable. As the Scrum Master, being the process referee is part of your job, and that includes calling out hand-wavy "action items" that aren't actually actionable or measurable. Get the Scrum Team to focus on using the Sprint Retrospective to continuously improve process in a measurable way, rather than just kvetching about things that the team can't or won't take responsibility for addressing in a self-managing way.
Two cases come to my mind
Once you clarify that everyone is ok with sharing that information and you decide that it's a valuable information to share, great.
My suggestion in how to share them would be based in a bullet from this answer
Do a retrospectives on how you have been improving as a team
So in the next retrospective you could bring up that concern of yours. Something like
During the last retrospective we identified we should do X, Y and Z during the next Sprint. Yet, we didn't consider them. Do you think these are still actions that need to be done? If yes, what's do you think it's blocking us from doing so? And how could we ensure it gets done?
Remember that as a Scrum Master...
... has the attitude of helping the team to solve its own problems rather than solving the problems for the team
We rarely have more than one item raised per sprint that we can do anything about so we raise them as stories and track them in the following sprint (or however long we're working on them).
We're an internal IT team so there's nothing from a retro that we wouldn't put on a board that our PO can see. Transparency applies to these items as to anything else.
Sprint Retrospective Itemas a WIT. Use those, and put them in a place the team can access them (a dashboard query perhaps). Use the items to inform your definitions of, and/or your sprint goal.