Value Stream Management: Value Stream Results by Gabriel Cassarini and co-author Alonso Álvarez
This series’s previous article presented the Flow Framework metrics to measure the value stream results. These metrics show different parameters of the teams’ activity, such as workload, velocity and flow efficiency.
Our goal with this article is to see how we can establish a relationship between these metrics and business results.
How do we measure value in software production?
When we talk about the value, we refer to the business value generated by implementing a feature, an epic, fixing a defect, etc. Value manifests itself in different ways: cost savings, increased profits, increased customer retention, new opportunities, increased user satisfaction. In some cases, assessing the impact of activities is relatively simple, and teams can quantify it: “Migrating the application to the cloud generates savings of €10,000 per month”. But in general, measuring value and impact is a complex task. In any case, we can establish a specific correlation over time between the team’s activity and the results obtained. By the way, the benefit is not always monetary. For example, the value of a spike is the learning obtained to make technical decisions, the value of paying the debt resides in an improvement in the agility of the teams, etc.
There are many ways to approximate the measurement of value. The Evidence-Based Management (EBM) framework, developed by Ken Schwaber and Scrum.org, proposes measuring, managing, and increasing the value delivered by teams acting in 4 areas: Current Value, Time to Market, Ability to innovate, and Unrealized Value. In addition, it establishes metrics, such as revenue per employee, customer satisfaction, team satisfaction, defect correction trend, etc. It is an empirical approach primarily oriented to software development.
Measuring business results in Flow Framework
Flow Framework is along the same lines as EBM and establishes 4 metrics to measure the results of a value stream: Business Value, Business Cost, Quality and Happiness. Let’s see the details:
It is the benefit generated by the value stream in business terms. If it is an end-user product, we could measure value by looking at recurring revenue, the monthly number of active users or the renewal rate.
We are looking for answers to questions like: “Is there any correlation between the reduction in Q1 Flow Time with the increase in revenue in Q2?”
The values for this metric should be obtained directly from the finance or marketing team, and the data must be disaggregated for each value stream.
Sometimes it isn’t easy to quantify value. For example: What is the economic benefit generated by a software platform’s components that are used internally? What about the value generated by a billing application? In these cases, we should use indirect metrics.
Value Stream Cost
It refers to the total cost of delivering value. It includes all direct and shared costs—for example, internal and external personnel costs, licensing expenses, infrastructure payments, etc.
Correlating this metric with historical Flow Efficiency, we could get answers to this, “Did the improvement in flow efficiency achieved in Q3 translate into cost reduction in Q4?”
In his book “Project to Product,” Mik Kersten comments that if each team is dedicated to a single value stream, accounting for costs is simple. The inability to quantify the cost generated by each value stream is an example of why a project-oriented approach is not scalable. If it is not possible to reliably measure the costs of a value stream, it is also not possible to determine the benefit created by each product. This lack of visibility reduces the agility to manage innovation investments more dynamically.
Value Stream Quality
It is the quality of the product delivered by the value stream from the customer’s point of view. There is some correlation between quality metrics and the performance and productivity of the teams and, by extension, of the organization. We can measure, for example, the incident rate. Some metrics can act as leading indicators of quality. For example, the age of items, i.e., the time elapsed since they entered the flow.
The Value Stream Quality metric analyzed in conjunction with item distribution history would help answer: “Has the time spent paying down technical debt during Q1 reduced defects in the next release?”
As was the case with cost, it is crucial to have independent quality metrics in each flow. This way, if it is decided to accelerate the release of certain functionality at the expense of sacrificing quality, this would be reflected in the metrics- just as the economic impact would be reflected in the value metric.
This metric seeks to measure the temperature and health of the team in each value stream. Motivated and engaged people are more productive and creative. Some organizations use the Employee Net Promoter Score (eNPS).
Again, establishing correlations between this metric and others would help us answer: “Is there any correlation between the team’s Flow Load reduction in the previous quarter and the eNPS level we obtained last week?”
Team health has many dimensions, and metrics should never wholly replace personal conversations.
Flow Framework enables linking metrics and results
The workflow for a value stream should maximize value delivery, minimize delivery times, and make the process as smooth-that is, predictable-as possible. Sometimes these objectives are conflicting, especially when there are dependencies between teams. In software development, value delivery occurs at the point of release of the technical solution-when we put the deliverable in the customer’s hands. Building solutions incrementally and making frequent releases reduces risk and accelerates the delivery of value and the realization of benefits. It allows you to influence the development process by looking at its direct impact on business results. Measuring results will enable teams to close the gap with business areas and speak their language.
We have seen that the Flow Framework defines metrics at the value stream level focused on the customer and the delivery of business value. That allows us to approach software development from a more product-oriented perspective. By connecting the work of teams and the tools, they use to plan, build, deliver and support, it is possible to measure the end-to-end value stream in real-time. And thus, make adjustments more pragmatically with an eye on the achieved results.