Retrospective - how to manage too many issues?
Trying to understand if I do right or is any other better way exists to manage the too big issues list for Retrospective.
We have about 12 issues for a retrospective. Some of them are from the last sprint, some from other sprints. Issues are different - personal performance, communications issues, process issues.
What we usually do is voting for the top 3 priority and then work with creating insight for them. Other issues are going to backlog.
Is it the right way to do this, or is better to generate insight for all issues and then choose what we want to do?
Can we really solve all problems at once? or do we tackle the once that have the most impact? How do we hold ourselves or those volunteering to solve those problems be accountable?
What we usually do is voting for the top 3 priority and then work with creating insight for them. Other issues are going to backlog.
Is it the right way to do this, or is better to generate insight for all issues and then choose what we want to do?
Why not use time-boxing to help achieve the right level of insight when you need it?
Did you do a retrospective of retrospective and ask the team? What did they say? 🤔
With respect to how you go about implementing improvements from Sprint Retrospectives, the Scrum Guide has the following relevant sentences:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
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.
To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
Personally, I've found it helpful to maintain a backlog of process improvements identified at retrospectives. It's useful for keeping track of conversations around each improvement item as well as identifying issues that occur several times. Like a Product Backlog, a process improvement backlog can be ordered by the team based on any number of factors and the team can self-organize around what items remain relevant and when to implement improvements from the backlog.
It may be useful for the team to have a conversation about how to execute their process improvement. The Sprint Retrospective is a good place to have this conversation.