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:
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.