Value Delivered via Working Software tracks how frequently a team releases functional, customer-visible features that contribute to desired business or user outcomes. Unlike traditional delivery metrics that focus on velocity or volume, this measure focuses on the impact of shipped software.
It reflects the Agile principle that “working software is the primary measure of progress”, encouraging teams to move beyond story points and towards outcome-centric thinking. The aim is to ensure that effort is converted into meaningful value, not just deployed code.
Count of valuable features or enhancements released to production within a time period.
Qualify “valuable” as functionality that meets a defined outcome (e.g. satisfies a customer need, improves an internal metric, or supports a business goal).
This can be derived from a tagged backlog (e.g. epics with outcome KPIs or linked OKRs).
There is no strict numerical formula, but suggested approaches include:
Volume-based:
Number of outcome-aligned features released / Total features released
Progress-based:
Number of features tied to OKRs or goals marked as “achieved”
Trend-based:
Track releases per week/month/quarter, filtered by value tags or outcomes met.
Tag backlog items as “value-driving” or link them to OKRs, KPIs or user goals.
Use delivery tools (e.g. Jira, Azure DevOps) to group and filter completed work.
Supplement with analytics tools to confirm usage or outcome achievement.
Establish clear definitions of value with product, user research, or stakeholders.
There are no industry-standard benchmarks, as the definition of value is context-specific. However, high-performing teams typically:
Release small, valuable increments every sprint or few days.
Have a high proportion of delivered work linked to measurable goals.
Use feedback loops (e.g. A/B testing, telemetry) to confirm value realisation.
Focuses on outcomes, not output: Helps teams avoid the trap of delivering work that doesn’t matter.
Enables product learning: Frequent delivery of working software supports rapid validation of assumptions.
Drives customer and business value: Ensures engineering effort is aligned to what users and the organisation truly care about.
Supports Agile maturity: Reinforces the core principle that progress equals real, usable functionality.
Define “value” collaboratively with product, business and users.
Use user story maps and benefit hypothesis templates to frame backlog items.
Tie epics or features to specific KPIs or objectives.
Review each delivery increment for evidence of impact or learning.
Prefer smaller, testable releases over large, delayed ones.
Treating any delivery as value, without validating impact.
Counting internal technical work or enabler tasks without downstream outcomes.
Lacking clear goal linkage, making value attribution difficult.
Delivering features but not enabling or activating them with users.
Frequent delivery of customer-visible software that moves product or business metrics.
Teams can clearly articulate what value a release is intended to achieve.
Retrospectives and reviews discuss outcomes as much as outputs.
Product, engineering and stakeholders are aligned on what “value” means.
[[CoE/Agile/Measures/Value Realisation/Feature Adoption Rate]]
[[Customer Value Lead Time]]
[[OKRs Met]]
[[Customer Feedback to Deployment Cycle Time]]
Accelerate (Forsgren et al.): Delivery performance is best measured by outcomes over effort.
Agile Manifesto: “Working software is the primary measure of progress.”
Evidence-Based Management (Scrum.org): Suggests measuring current value, time to market, and ability to innovate through delivery outcomes.