How do we ensure that the Retro Actions get executed?
Retro Actions hanging around and carrying over more than one Sprint. Assignees with no time to execute and forget about them.
Bad for morale and weakens the Retro.
How can we ensure these Actions are executed?
We are using Azure DevOps/TFS and we're tried adding Tasks and Items to the Board but to no avail.
Do you know why what you're doing isn't working?
What you're trying seems consistent with what the Scrum Guide suggests, in that each Sprint Backlog "includes at least one high priority process improvement identified in the previous Retrospective meeting." Since the Sprint Backlog is visible, it shouldn't be forgotten about. It can also be considered during Sprint Planning to make sure that there is time set aside in the Sprint to take on that improvement work.
What stands out to me is that you find "no time to execute" and the team "forgets". I'd want to understand better what is happening in Sprint Planning and how the team is creating, maintaining, and using the Sprint Backlog (especially at the Daily Scrum).
For what it's worth, this is the approach that I've used. I've tended to use Jira, so I'll either create an issue type or a project for process improvements and make sure that those are visible and ordered. Making sure to pull at least one into each Sprint and considering it when determining capacity for other work has helped a lot.
How can we ensure these Actions are executed?
It sounds to me as though one Retrospective improvement might be to adjust Sprint Planning capacity so any other improvements can be made.
Once Sprint Planning starts, enact immediately.
Assignees with no time to execute and forget about them.
What are the Scrum Team saying yes to that means they have to say no to these improvements?
Do they realize the impact of saying yes?
To go in the way of Simon, what is at stake for them ? Is it worth doing the actions of Retrospective for them ?
If we take the evolution concept, if they keep it in the gray zone instead of doing better, they should have a hidden interest.
What is their interest of staying like they are ?
Just laziness ? or fear of breaking things ?
just motivation: they don't really believe in the retro actions?
maybe there is something like psychological safety, I mean some people are taking the lead so other team members don't express themselves ? So everybody says yes without real debate ? maybe anonymate vote would be required ?
@Thomas and @Ian are right here. The improvement item is either not visible enough in the Sprint Backlog or your whole team has too much development work selected for the Sprint leaving no space to deal with Retro actions (or both?).
Perhaps you could "smuggle" them into the Sprint Goal if it's something that's seriously impacting your team's performance or internal communication? As long as it makes sense to put them there and you won't lose focus from what's most important during the Sprint - delivering a "Done" Increment.
Another possibility that came to my mind is that the Retro items seem too difficult/ time-consuming - therefore you and your colleagues start to think that they will be left with not enough time to finish PBIs with higher priority? Kaizen can be of help here - you could split Retro actions into very small steps/ sub-actions, making them ridiculously easy to execute even on a daily basis, throughout the Sprint. If possible of course... Execution of small steps could bring you closer to your desired outcome each day. It's still better than leaving those actions hanging in the Sprint Backlog and moving to next Sprints.
[1] Scrum Guide:
https://www.scrumguides.org/scrum-guide.html#events-retro
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
[2] Add the retrospective actions added to product backlog
[3] We need to capture the retrospective action in a tracker ( excel based, confluence, etc.) and track