Quantify your retrospectives to unleash the full power

[#1]

How do you conduct retrospectives in your team? Do you use Confluence or Miro with techniques such as ‘start, stop, continue’ or 4L? How do you quantify whether your team has become better over a time period, whether it’s a year or a quarter? I assume you don’t, because extracting data from visualization tools or wiki pages, which are sometimes chaotically outlined over a year, is not an easy task.

How many times have you labeled a problem as "TBD", which eventually ended up in a backlog of other "TBDs" that you later had difficulty prioritizing? What if some of these "TBDs" even required approval from top management, such as budget approval to allocate more compute for faster compilation or to run heavy tests? I assume in half cases you give up in providing robust data for justifying budget allocation or prioritization of problems.

I’ve been there many times before I implemented the solution for JIRA - Multi-team Scrum Metrics & Retrospective. It's obvious that one of the most crucial parts of the retrospective is analyzing failed commitments, which in most cases involve incomplete scope. I found that the most effective way to improve over time is to analyze failed work items on a case-by-case basis, according to some metric over a time period - be it a sprint, month, quarter, half-year, year, or release in PMIS (task tracker). To do that, we need:

1. Visualization, for example, bar charts. Each bar represents a specific metric - Uncompleted Scope, Unestimated Scope, etc. Bar charts can be constructed for sprints, months, quarters, half-years, or years to track progress over time for various metrics, with the ability to do so across several teams if they, for example, work in the same domain and share a common backlog. It’s best to be able to construct custom metrics as well, as some teams may have their own success criteria.
   
   
2. Retrospect in-place – the ability to click on a bar, see the list of failed work items, choose the reason(s) from a pre-defined but customizable dropdown, and describe in a text area how to prevent it in the future, all in the same view.
   
   
   
   
3. Report on top reasons for mediocre performance over any time period - sprints, months, quarters, half-years, or years - with the ability to compare periods (e.g., 2024 vs. 2023 for one team or multiple teams, such as domain (team1, team2) ABC: 2024 vs. 2023). This will allow you to see how the reasons have changed over time.
   
   
   
   
4. Report on metrics with the ability to drill down – display the visualization from item 1 with the ability to drill down into sub-periods. If the reporting period is a year, during the reporting session, we may need to understand how work items were distributed across the year. In this case, we can drill down into half-years, quarters, months, or sprints within the same view
   
   
   
                                                                ...
   
   

With all four items implemented, you will find that the questions outlined at the beginning are no longer an issue for you:

• You will have quantifiable outcomes of retrospectives that can be viewed in two formats - bar charts with metrics and pie charts with the list of reasons for failed metrics - across sprints, months, quarters, half-years, or years.
• To see all the work items that failed due to the same reason, you can just click on the reason from the report described in item 3.
• To understand which impediments are the most crucial and need to be resolved, you just need to view the report containing an ordered list of reasons with the number of failed work items next to them, as described in item 3.
• Justifying budget allocations or any discussions with top management on why we are failing or progressing slowly becomes much easier when you can support it with easily collected data.

The framework above can be a bit tough to implement, but once you do, you will certainly open the route to unleash the full potential of your team. Thanks to the framework last time I with teams archived:

• 2x increase in delivery throughput/velocity
• 3x increase in flow efficiency
• 4x increase in planning accuracy and team commitments

Previously I used several workarounds and 3rd party apps to implement part of the functionality outlined above in JIRA, but at some point I just decided to implement it as an app - Multi-team Scrum Metrics & Retrospective.