Scrum Masters: Level Up with Hypothesis-Driven Improvement

Do you struggle to make meaningful improvements to your team? Do your retrospectives lack enthusiasm and the benefits of continuous improvement? Retrospectives are supposed to be the time for the team to reflect and focus on how they can improve.

During retrospectives teams often discuss impediments and add these items to their backlog for a future sprint. However, these items often lack sufficient details and result in limited improvement.

An Improvement is:

• The act or process of making something better
• The quality of being better than before
• An addition or change that makes something better or more valuable

Luckily, these are all measurable. This means that when delivered, those quantifiable changes can be easily and clearly measured by the team.

A few years ago I started to experiment with how we could make meaningful improvements in our team. We did not have spare cycles to waste on improvements that did not make us better. Our retrospectives were not digging deep enough to identify where the problem was. More importantly, we did not even have a sense of what benefits we would achieve by doing the improvement.

So we made an adjustment in our retrospectives. If there was an impediment or issue that was slowing us down we would do the following to assess the backlog item:

1. What problem are you trying to solve?
2. How do you measure this problem today?
3. What benefits are you hoping to gain?
4. How will you measure success?

Why were these questions important? Let's take a closer look.

What Problem Are You Trying to Solve?

This might seem obvious, but surprisingly it is usually a big gap. Once we focused on this question as our entry point, we were able to eliminate "improvements" that wouldn't get to the root of the problem.

For example, we had an issue around inaccurate estimating. When our team sat down and really described this problem we kept coming back to the health of our backlog or technical gaps in our solution. The problem identified around estimating was a symptom, not a root cause.

How Do You Measure This Problem Today?

Previously, we could never measure how estimating was an issue, but we could easily show that our estimates were bad because we did not understand a backlog item correctly. Now that it's measurable, we have a great baseline to test our improvements against. This also helped us further de-prioritize low value improvements. If we could not measure the impact or frequency then we knew there was no value in trying to fix it.

Once our problem was clearly defined and we understood how we could measure this impact, the next thing to decide was how we wanted to improve. It was very important for us to understand what benefit the team would get by doing this improvement.

What Benefits Are You Hoping to Gain?

By taking time to define the benefits we could gain, we had an opportunity to really understand the value the team could attain. Identifying the value was a key piece of information that really helped us to filter, refine and prioritize our improvements.

How Will You Measure Success?

In order for our team to understand if we made our improvement we had to know how to measure the impact. Measuring our improvement was a key driver for us to understand if we were improving or needed further investigation in a certain area.

Once we started to capture our improvements with this format we started to gain traction on making meaningful improvements. Eventually it led us to change our third point. The question "what benefits are you hoping to gain" became an experiment — because the benefits we were describing were actually the result of us trying something. So we settled on a Hypothesis for our third point — maybe it was a familiar format to a User Story that connected with us.

So if you are looking for a way to inject some new life into your improvements, consider using the Hypothesis Driven Improvement (HDI) method. It really works!