The work of impediments is, in many ways, no different to the work involved in delivering solutions. The outcome has a different nature (improvement vs value) but the way it is worked is similar.

It should be no surprise that we can use the same kind of metrics to track the work on impediments as we’d use for any other work. Good metrics to start with include:

• (V)alue: What stakeholders get out of the work the team delivers. While there is nothing wrong with getting direct opinions from the stakeholders via, say, and Net Promoter Score survey for work completed, in many cases you will have a more direct understanding of the value delivered as a result of the metrics used to track which experiments help the most. And while you might not start with this metric, in the final analysis impediment removal is about increasing the efficiency of your delivery process - improving the flow of value delivered. A “before” and “after” (impediment removal) view of the delivery “value stream map” will help you understand the impact you are having.
• (O)utput: How much work the team delivers. Is the impediment team able to increase how many impediments are resolved over time - “Impediment Resolution Throughput”.
• (R)esponsiveness: How fast the team delivers resolution to impediments. Are we able to reduce the time required to resolve impediments - “Impediment Resolution Cycle Time” or “Impediment Resolution Lead Time”.

In addition, since there are potentially issues associated with our people raising impediments, we need to track the inflow of work. Are we seeing a “healthy pipeline” of impediments? In general, you should see more demand (more backlog of impediments) than supply (your ability to address the impediments.)

And finally, I’ve found that it is sometimes helpful to capture “man-hours saved” type metrics, and display this data very visibly in the office somewhere. This is something everyone can easily understand. Taking the example above, if we were able to work the security issue so that there was no documentation requirement (perhaps we have automated the process) then every time we release a new feature, we don’t have to do that work, which means this capacity can be applied elsewhere. Say that developing the documentation took 1 week every time and we deliver 10 features every month. Then … wow … you get the idea.