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.
Retrospectives are for Identifying and Defining Adaptations
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.
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.