Have you thought about using business value as a measure of agility in your organization? Are you running into challenges? Learn how to measure DevOps performance with a data-driven approach to deliver more value to your customers and check out our webinar, Measure DevOps Performance with VersionOne.
The Goal of Data Driven DevOps
DevOps can be any optimization that streamlines the flow of business value between developers and customers. That optimization can be anything that improves the value stream:
In Gene Kim’s book, the DevOps Handbook, he talks a lot about telemetry and how to measure DevOps overall. Much of his focus is largely on the output of what I call the DevOps machine.
There is a missing piece in that book. It is important to measure the output of the DevOps machine, but you need to measure the DevOps machine itself. You need better telemetry about the DevOps machine in terms of its ability to move value from the developer to value consumers.
The goal, from our standpoint, is to tightly couple DevOps reporting and measurement with the delivery of business value at the center. These come in the form of flow metrics and risk metrics.
The Problem with Business Value
There are a couple challenges to measuring the flow of business value. The first is accurately defining and agreeing on what is business value? In the world of software development there is not a standard unit of flow, so there is not a standard unit of business value.
At the famous doughnut shop Krispy Kreme, for example, the unit of value is really easy to figure out. In our world, it’s much more complicated. Mark Schwartz, has written a book, the Art of Business Value. Schwartz reviews different examples of ways that you might calculate business value, and they range from very complex to more simple calculations, but they’re all subjective. At VersionOne we looked for something that’s much more objective and easier to measure.
A Proxy for Business Value
Since we have a hard time objectively measuring business value, we looked for a long time for a proxy. If we can’t actually measure business value, what can we measure? What’s the next best thing?
We determined it is the backlog item, either a user story or defect as that standard unit of flow through the DevOps value stream. I know that’s imperfect to say the least, so let’s weigh the pros and cons.
First off, value is typically not delivered at the story level, it’s consumed at the feature level or even higher than that, so stories might have no value.
Second, it’s almost impossible to calculate the dollar value of a user story or a defect. People try and some people estimate and there are different theories about how that might work, but I don’t know that anybody’s really perfected that.
That being said the pros outweigh the cons. The pros to using backlog items as a proxy for value are:
- Uniform in size
- Simple to track and measure
- Easily affiliated with source code
- Highest value item worked on next
The premise of backlog item prioritization is that you should always be working on the item provides the optimal value. Our assumption is if we’re working on a backlog item today it’s because we collectively believe it’s the next most important thing.
The reason why being easily affiliated with source code is so important is because once you convert backlog stories into source code it is much more difficult to trace that source code back to the original strategic initiative.
This is just a small excerpt from our webinar, Measure DevOps Performance with VersionOne. Watch the full webinar to learn how we’re working at VersionOne to make business value more central to measuring DevOps performance and the importance of batch size as a measure of overall DevOps maturity. Stay tuned for part two of this blog, Measure DevOps Performance with VersionOne, where we will dive into some examples of how companies are using VersionOne to measure DevOps performance.
VersionOne is a registered trademark of VersionOne Inc. and Continuum is a trademark of VersionOne Inc.