Metrics – Driven Retrospectives

The Scrum methodology is driven by the Kaizen mindset, which refers to continual improvement. However, the success of the Kaizen mindset depends mostly upon Sprint Retrospectives. In this article we will discuss Metrics – Driven Retrospectives and their importance for a company’s success.

Based upon the Scrum Guide 2020, the Sprint Retrospectives enhance quality and effectiveness in a process. These Sprint Retrospectives are also known as Metrics-Driven Retrospectives.

Companies classify Metrics-driven retrospectives as:

• Qualitative metrics.
• Quantitative metrics.

During the retrospectives, we can collect qualitative data by surveying the team members.  The Three Important Pillars of Data Collection and Empirical Process.

• Transparency
• Inspection
• Adaptation

For transparency, a psychology is for everyone to speak what is present in their minds. It starts by reviewing the progress made to the action items recognized in the previous retrospective and then discussing the success and failures of the past Sprint.

Inspection comprises the leading causes of events that have occurred. We can count it by spending some time with the Scrum team and determining the cause of the events.

Adaptation refers to the acceptance of changes for becoming truly agile. In adaptation, the aim is to walk out of the retrospective with actionable items to resolve significant issues and improve the work approach.

Just like qualitative metrics, companies can collect quantitative metrics during the Sprint. Among them, some of the commonest are:

• Lead time
• Cycle time
• Number of escaped defects
• Delivered features
• Sprint velocity
• Feature-bugs ratio
• Committed features, and
• Throughput, etc.

 Scrum metrics that teams should use for self-improvement are:

• Throughput
• Time-to-Market/Time-to-Value
• Escaped Defects/Quality
• Bug Created versus Bug Closed

It is the number of finished product backlog items per product. It is comparatively better than the sprint velocity.

It is the length of the number of sprints before the release of the team to the end-users.

It is the representation of software faring in production. Scrum masters can facilitate this metric by defining a defect that is considered a bug-issue type.

It represents a bug created versus a bug closed in a sprint and all the cumulative values. This metric helps understand the code quality and attaches the Sprint team closely with the escaped defect metric. The bug created versus bug closed gives a complete view of the software quality.

With all team members having a real-time view of the metrics, they become an essential part of the everyday sprint retrospective reviews.

In Scrum, the ability to show continued improvement is critical. Therefore, the metrics to measure this Continuous Improvement (CI) are also essential. To become Self Improving (SI), the Scrum teams should own and drive the CI themselves.