Measuring Value Flows in Software Delivery with the Value System Schema

Full text

1 Introduction

Software teams are measured closely: velocity, throughput, lead time, deployment frequency and change failure rate are collected automatically. Yet these numbers leave one question open: what value did the team deliver, to whom, and at what cost in losses?

This paper proposes a method for answering that question with the Value System Schema (VSS), the modelling notation of the Æilus methodology, as implemented in the VSS Editor published on aeilus.tech. It is the fifth paper of the series "Æilus for Business". It uses the vocabulary defined in the first paper of the series, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), and does not repeat those definitions. The formal treatment of value as a measurable currency (Æ) is given in "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

The paper describes how a delivery organisation can build a schema of its value system, attach planned and realized value to releases, locate flow resistance and leakage, evaluate shared technical nodes, and run the cycle with clear roles and cadence. It relies on VMT axioms A1, A2, A4, A5, A6, A7, A11 and A13 and theorems T3, T4, T5, T6, T8, T9, T15, T16 and T17. It contains no measured data. The worked example in Section 9 is synthetic.

2 What delivery metrics measure and what they do not

Delivery metrics describe the motion of work. Velocity counts estimated effort completed; throughput counts items finished. The four key metrics popularised by Forsgren, Humble and Kim (Accelerate, 2018), namely deployment frequency, lead time for changes, time to restore service and change failure rate, describe the speed and stability of the delivery pipeline. That research links these capabilities to organisational performance, and this paper does not dispute it. Its claim is narrower: these metrics describe the pipeline, not the value that passes through it.

Three gaps follow from this.

• Effort is not value. A sprint with high velocity can deliver features that nobody uses. In the language of the Product Value System deck, "features are not value" and "metrics are not value": a feature is an assumption about value, and a metric is an interpretation of it.
• Speed is not direction. A short lead time delivers a wrong hypothesis faster.
• Stability is not the absence of anti-value. A low change failure rate says nothing about delay, confusion, rework on the user side or loss of trust caused by a change that worked exactly as designed.

From the point of view of Value Management Theory (VMT), the gap is structural. Value exists only inside a defined value system and is interpreted by its actors (A1, A2). It is realized at the moment of consumption (A6), and planned and realized value usually differ (A4, T3). Pipeline metrics are collected before consumption, on the sender's side, so they describe at most the delivery of planned value. When such metrics become targets, the effect described by Goodhart (1975) appears: teams optimise the counter. VMT states the same risk in system terms: local optimisation does not guarantee global improvement (T5).

3 The Value System Schema notation

3.1 Elements of the notation

In the Æilus methodology, the Value System Schema is the first core artifact: a formal description of the value system, its actors, flows, transformers and key exchanges, used to establish system boundaries and to prevent invisible external dependencies. A VSS can be drawn at the transformer level or at the system level.

The VSS Editor, released on aeilus.tech in December 2025, is a browser-based visual editor for such schemas. Its notation has a small number of elements.

• Converters. A converter is the Æilus name for a transformer role in a schema: a functional block, such as a team, a service or a subsystem, that receives value elements, transforms them and produces new ones. Converters are where value is created, amplified or destroyed.
• Flows. A flow is a directional connection between converters, or between a converter and the outside world. It carries an amount of value or anti-value in Æ. A flow is external in (value entering the system), external out (value leaving the system) or internal (value between converters).
• Inputs and outputs. External inflows and outflows mark where value enters and leaves. Together they define the system boundary.
• Value elements. Element types describe what exactly moves through a flow: customer value, revenue, costs, risks, technical debt and similar. In a saved schema each element has a kind (value or anti-value), a sign, a quantity and a unit (Æ).
• Anti-value. Anti-value represents losses and negative effects: delays, rework, defects, bureaucracy, risk, burnout, wasted effort. In the schema it is an explicit element with a negative sign, not the absence of value (A5).

3.2 The schema as a machine-readable model

The editor saves a schema as structured JSON with nodes (converters), flows and elements. The schema can therefore be versioned together with the product, and later read by analytics that compare planned and realized quantities per flow. Such analytics are announced as future work and are not assumed here.

3.3 What the schema is not

The VSS Editor is explicitly not a KPI dashboard, a BI tool, a simulation engine or a replacement for financial accounting. It puts clarity before calculation. The recommended modelling order follows: define the boundary, add major converters only, connect them with named flows (names before numbers, direction before precision), then mark anti-value, the step that often produces the most insight.

4 Whose value: the system and its boundary

A measurement of value is meaningless until it states whose value is measured (A1, T1). The boundary chosen also changes the conclusions without any change in reality (T15). This paper therefore fixes the value system before any measurement.

The value system modelled here is the product value system of a single software product inside a product organisation. Following the Product Value System deck, its actors are the product function, the development team, operations, the product in production, the users, and the company as recipient of value returned by users. Finance is an external enabling inflow (salaries).

Two realized interpretations are measured: value for users, interpreted by users or their observable behaviour, and value for the company, interpreted by the company as receiver of the return flow (revenue, retention, reduced cost or risk). Planned value is the sender's interpretation before release. The value of the same release to a partner or regulator is outside the boundary unless it is extended explicitly.

5 From product hypothesis to realized value: the value loop

The Product Value System deck frames product work as a loop in which value hypotheses are created, implemented, validated and sustained. In schema terms the loop has the following converters and flows.

1. Investment to product function. The product function converts resources and user signals into hypotheses carrying planned value.
2. Product function to development. Hypotheses become backlog items with planned value. The deck states two expectations: the planned value of a hypothesis should not decrease while it is being built, and delivered value should not differ much from planned value.
3. Development to operations. Development consumes effort and produces working changes, together with anti-value (technical debt, defects, delay).
4. Operations to production. Changes become running software; release errors and downtime appear as anti-value.
5. Production to users. Value is realized only in use (A6), so this is the first point where realized value can be observed.
6. Users to company. Users return revenue, retention and trust. The author's channel post of January 2022 calls this a closed flow: value delivered to the client is balanced by value flowing back, often but not only money.

The loop makes the transformation axiom concrete (A7): each converter realizes what it receives and produces new planned value for the next one. It also shows why pipeline metrics cover only steps 3 and 4. Steps 1, 2, 5 and 6, where value is planned, realized and returned, lie outside the pipeline.

The deck also lists observable element types for internal and external products. Value elements include time saved, fewer operational errors, cash flow, risk reduction, lower cognitive load, predictability, new capabilities and trust. Anti-value counterparts include lost time, rework, growing operating cost, technical debt, unpredictability, manual workarounds, loss of trust and degraded customer service. This typology is the starting point of a Value Element Registry for delivery.

6 Planned and realized value per release, resistance and leakage

6.1 The release as the unit of comparison

The unit of comparison is the release, or the backlog item when releases are small. For each, the method records in Æ:

• planned value: the sender's estimate, recorded before development starts and updated only through an explicit, logged decision;
• realized value and realized anti-value: the receiver's interpretation after the release has been in use for an agreed observation period;
• retrospective value: a later re-evaluation, once second-order effects (support load, churn, technical debt) have become visible.

The deck proposes a staged introduction: first planned value on every backlog item, then realized value and anti-value on every released item, then retrospective value. Without planned value there is no gap to measure; without realized value the plan remains a hypothesis.

6.2 Flow resistance in delivery

Flow resistance is the gap between planned and realized value plus the anti-value that appears in a flow. VMT treats a non-zero gap as normal (T3) but holds that resistance accumulates historically (T4) and reduces the ability to realize future value (T6). In delivery, value is lost in implementation (scope cut, misread hypothesis), in release (defects, rollbacks), in adoption (users cannot find or use the change) and to delay. Following the cost of delay concept (Reinertsen, 2009), delay is modelled as anti-value on the late flow, not as a separate metric.

If each flow carries its own planned and observed quantities, the schema shows in which converter the loss occurred. This is the purpose of the Flow Resistance Register and the Planned vs Realized Value Gap Report in the Æilus artifact set.

6.3 Leakage

Leakage is a sustained excess of realized value leaving the system over value entering it (A11). In a product value system two forms are common. In the first, users benefit but the return flow does not cover the enabling inflow. In the second, the team consumes investment while hypotheses are built but never realized. Throughput can look healthy in both cases; the schema shows both because inflows and outflows sit on one boundary.

7 Shared nodes: evaluation across all flows

Some converters in a software system produce no value that a user would name, yet every value flow passes through them. The author's channel post of September 2025 and the related aeilus.tech article use authorisation as the example: it generates no value by itself, but without it every scenario stops. An API gateway or a CI pipeline is of the same kind.

Evaluated in isolation, such a node shows cost and no output and invites cost cutting. In the schema it appears on many flows at once, and its efficiency becomes clear only through the aggregate value of all the flows it supports. The method therefore assigns to a shared node:

• the set of flows that pass through it, read from the schema;
• the anti-value it adds to each of those flows (latency, outages, failed logins, integration defects);
• its consumed value (team effort, infrastructure).

Its efficiency is delivered value minus anti-value across all its flows, set against consumed value, following the process efficiency definition of the same article. A degradation in a shared node is never a local incident; it is resistance added to every flow it serves. Theorem T8 adds a sustainability argument: stability is lost when a transformation role cannot be performed, and redundancy of the role increases stability.

8 What a team leader gains

The author's channel post of February 2022 lists what the approach gives a team and its leader. Restated in the terms of this paper:

• Delivered value as feedback. For any period the team sees the value it delivered, in Æ, confirmed by recipients, instead of the indirect signal of velocity.
• An effectiveness measure independent of process methodology. Whatever the practice, the measure is realized value per consumed value, and practices are selected or retired by their effect on it (P7).
• Transparency for the business. Technical work becomes explainable through the flows it supports.
• Backlog priority from value. Priority can be derived from planned value, its confidence and its cost of delay, instead of from the loudest stakeholder.
• Cost of delay and production errors as anti-value. The business can show how value falls when a change is late or faulty, and the team sees how the usefulness of its work depends on timing and production quality.
• Arguments for shared resources. Where administrators and DevOps engineers are shared, value-based priority explains why one team's work was deferred in favour of another's, in both directions.

These gains hold only if realized value is validated by its recipients. If the team estimates and confirms its own value, the measure becomes another self-reported counter, and T17 applies: interpretations from influential sources that are not confirmed by realization accumulate anti-value.

9 A worked schema of a synthetic product

This section describes a synthetic, illustrative product. It is not a case study, it does not describe any real organisation, and it contains no measured numbers.

The synthetic product is a subscription web application through which small service businesses accept customer bookings. Its value system follows the boundary defined in Section 4. Two shared nodes, an authorisation service and an API gateway, serve all user-facing flows. Finance provides the enabling inflow. The company receives subscription revenue and retention as the return flow.

The schema is built in the VSS Editor in four passes: the boundary with one external inflow (investment and salaries) and the external outflows to users; seven converters; flows named by the value elements they carry; and anti-value elements. Quantities stay empty until the first estimation session.

Consider one hypothetical release: a reminder feature intended to reduce missed appointments. Before development, the product owner records planned value per element (time saved, fewer missed bookings, expected effect on retention). After an agreed observation period, product analytics and a sample of business users supply realized value, and the team records realized anti-value: a late release, a defect that sent duplicate reminders, extra load on the API gateway. The difference is the resistance of this release. The defect and the gateway load also sit on flows serving other scenarios, so they are assigned to the shared nodes too. A quarter later, retrospective value records whether retention changed at all. In a real application, quantities would come from the sessions described next.

10 How to run it

10.1 Who estimates and who validates

The Æilus rule from the 2025 post is short: the output value of a process must be assessed by the one who consumes it, and someone else should check that assessment. Applied to delivery, this gives a clear division.

• Planned value is estimated by the sender. For hypotheses this is the product owner, acting as Value Transformer Owner (VTO) of the product converter. For the development converter it is the team leader as VTO.
• Realized value is interpreted by the receiver: users, observed through product or web analytics, and the company for the return flow. The deck proposes, as a temporary measure, that product analytics represents the user side until direct validation is established.
• Validation of the interpretation is done by a second party: the Value System Owner (VSO), who owns system-level sustainability, or a Flow Owner for a critical flow.
• Methodological integrity is supported by an Æilus Master (in the deck, an Æilus champion held by a project manager), who prepares the value delivery, plan versus fact and flow resistance reports.

10.2 Cadence

Æilus does not prescribe a calendar. A minimal cadence for a delivery team, consistent with the methodology's recommended events, is the following.

• Per backlog refinement: planned value is assigned to new items, using the element registry.
• Per release, after the observation period: realized value and anti-value are recorded and validated; a short value retrospective discusses the gap.
• Monthly or per quarter: a Flow Resistance Review over the schema, including shared nodes; retrospective value for items released earlier.
• Per quarter or on structural change: a Value System Review of boundaries, converters and dependencies, with the schema file updated and versioned.

10.3 Discipline

Every artifact needs an owner, an update loop and a decision purpose; otherwise it creates anti-value through maintenance cost and false confidence. For this method the decision purposes are backlog priority, allocation of shared resources, release timing, and investment in shared nodes. Growth of planned value is admissible only when the team's ability to realize it is confirmed (P9). Scaling planned value faster than realized value is the failure mode described by T16.

11 Limitations and what an empirical study would need

This paper is conceptual and has not been tested on measured data. Several limitations follow.

• Estimation quality. Values in Æ are interpretations whose reliability depends on the estimators and their calibration.
• Partial commensurability. Time saved, revenue and trust are only partially commensurable (A13). Expressing them in one currency requires a Value Aggregation Policy, which this paper assumes but does not define.
• Attribution. Realized value often results from several releases and outside factors; the schema shows structure but cannot isolate one release's contribution.
• Hidden flows. If the schema cannot explain the observed stability or decline of the system, there are latent flows or the boundary is wrong (T9). A schema is a hypothesis about structure and must be revised.
• Cost of the method. Sessions that produce no decisions turn the method itself into anti-value.

An empirical study would need, at minimum: several delivery teams that apply the method for a period long enough to record retrospective value; a stable element registry and aggregation policy agreed before data collection; independent validation of realized value by recipients rather than by the teams; parallel collection of conventional delivery metrics, so that the relation between those metrics and realized value can be examined; and a comparison of decisions taken with and without the schema. Only such a study could show whether value-based prioritisation changes delivered value, and under which conditions.

12 Conclusion

Delivery metrics describe how work moves through a pipeline, not what it changed for its recipients; under VMT they cannot, because value is contextual, realized only in use, and planned and realized value diverge. The Value System Schema, as implemented in the VSS Editor, lets software teams draw the product value loop from hypothesis to realized value and back to the company. Recording planned, realized and retrospective value per release turns the loop into a measurement: resistance and leakage become visible, shared nodes are evaluated across every flow they serve, and team leaders obtain delivered value, value-based priority and the cost of delay and errors as feedback. The method stays honest only if the system boundary is stated, recipients validate realized value, and every artifact serves a decision. Whether it improves delivered value in practice is an empirical question that this paper frames but does not answer.

References

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (in Russian). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.