Using existing work management tools to connect anticipated outcomes, delivery performance, and actual results.
10 min read
Nearly every conversation I have about software development these days seems to turn to one of two topics: AI or outcomes. Yet despite all our discussions about outcomes, how often do we return after delivery to understand whether an investment produced the value we expected?
Outcome thinking isn’t new. Marty Cagan and others have advocated for it for decades, but I’ve noticed a broader industry shift from outputs to outcomes over the last three or four years. My own shift accelerated in 2023, following years of investment in Agile transformation, automation, delivery efficiency (Flow), and value stream management. I began focusing more deliberately on the business results of what we delivered, a journey that helped shape my book, Profitable Engineering.
Shortly after publishing the article Predictability vs. Outcomes: What Are We Actually Predicting?, I attended a Flowtopia session on Outcome Engineering with Helen Beal, founder and Chief Flow of Flowtopia.io, and Colleen Johnson, CEO and cofounder of ProKanban.org.
My previous article explored what we should expect when predicting and measuring business outcomes. This follow-up considers how we might put those ideas into practice.
Although I’d heard Helen and others use the term Outcome Engineering, I hadn’t applied it to my own work.
Steve Pereira and Andrew Davis use mapping practices in their book Flow Engineering to understand how value moves through an organization, identify constraints, and guide improvements. I see a similar opportunity with Outcome Engineering: establish the anticipated outcome, document supporting evidence and confidence, define how we’ll measure success, and return to evaluate actual results. Both approaches use evidence and learning to improve how organizations deliver business value.
This discipline begins before implementation. Clearly documented anticipated outcomes help inform investment decisions and connect the work teams perform to organizational goals. They also provide the sense of purpose Daniel Pink describes as essential to motivation, alongside autonomy and mastery. Comparing actual outcomes with those expectations then helps us learn and make better investment decisions.
Our Flowtopia discussion about extending delivery workflows to capture realization raised a practical question: How can we make this a repeatable practice using the work management tools we already have, without adding unnecessary process?
Separate Delivery Performance From Outcome Realization
Organizations use delivery performance measures such as lead time, cycle time, DORA metrics, and Flow Metrics, including Flow Time, Flow Velocity, Flow Efficiency, and Flow Load. These help us understand how work moves through our systems, identify constraints, and improve predictability.
For organizations measuring the full value stream from ideation through deployment into production, delivery completion establishes an important measurement boundary.
If a capability is delivered in October but its business outcome cannot be evaluated until January, keeping the delivery work open during that observation period would change what delivery measurements mean and when it counts as complete.
I prefer recording two distinct completion events associated with the same investment.
Delivery Done: The capability meets the team’s Definition of Done and is delivered and accepted. Delivery performance is measured using the organization’s established start and completion boundaries.
Realization Closed: The actual business outcome has been evaluated against the original hypothesis. The results, supporting evidence, and subsequent decisions are documented.
Both measurements belong to the same investment, but they serve different purposes. Separating them preserves delivery performance data while allowing us to evaluate whether the investment produced the anticipated business value, without requiring additional Kanban stages.
One Investment, Two Completion Events
The important distinction is that each has its own completion date and measurement purpose. A delivery item can be closed for flow reporting while a linked realization review remains open.
Make the Outcome Review Part of the Initiative
Consider a hypothetical SaaS company investing in a simpler subscription purchase process. The anticipated outcome is to increase trial-to-paid conversion from 12% to 16%, measured over an agreed 90-day period after release.
The initiative captures the hypothesis, supporting evidence, and the stakeholder’s confidence in achieving it. For example, the stakeholder might initially express 70% confidence in reaching the 16% conversion target. As discovery progresses, they revisit that assessment when new evidence emerges, preserving the original prediction and subsequent changes.
When the initiative is approved for implementation, a Product or business stakeholder takes ownership of evaluating the anticipated outcome. They ensure there’s a way to measure the result and establish when sufficient evidence should be available to review it.
When the capability is delivered, the delivery work closes normally. The outcome-review responsibility remains visible through a linked task or similar mechanism within the existing work management system.
After 90 days, conversion has reached 14%, below the anticipated 16%. The Product lead reviews the evidence, documents the actual result, and considers whether the purchase changes contributed to the improvement.
The next decision might be to refine the experience, investigate another assumption, or redirect further investment.
The initiative now contains both delivery performance and the outcome evaluation, preserving their relationship while allowing each to be analyzed independently.
Can Our Existing Tools Support This?
While a more comprehensive tracking solution may emerge, many of the work management tools we already use can support much of what we need today.
Most support custom fields, linked tasks or work items, due dates, ownership, and reporting. With some configuration, these capabilities can preserve the realization obligation after delivery and produce consistent data across multiple initiatives.
The specific capabilities and reporting options vary by platform and subscription.
Labels can help identify and filter work, but reliable analysis requires some structured information. At a minimum, I’d want the original hypothesis, accountable owner, review date, review status, actual result, and supporting evidence.
We should also preserve the original confidence assessment and meaningful changes to it rather than overwrite earlier predictions.
Business evidence may come from product analytics, financial systems, customer feedback, or other sources. The work management tool connects that evidence to the original investment.
This gives us a practical starting point without introducing another system solely for realization tracking.
Define What Closes the Review
I would establish separate completion criteria for delivery and realization, both connected to the original initiative. Delivery can close when its Definition of Done is satisfied, while the outcome review remains open until the results and subsequent decision are documented.
The review is complete when the responsible stakeholder documents the actual result, compares it with the original expectation, identifies significant limitations in the evidence, and records the resulting decision.
The outcome doesn’t have to meet its original target. An investment that falls short can still provide useful evidence for future decisions.
Some outcomes take longer to materialize, and others remain difficult to measure. If evidence is insufficient when the review date arrives, the owner should document what’s known and determine whether another observation period is justified. If further measurement is unlikely to be useful, the review can close with an explicit, inconclusive finding.
The responsibility remains visible and reaches a documented conclusion rather than disappearing when delivery ends.
Measuring Our Progress Toward Realization
In Profitable Engineering, I introduced the Feature Factory Ratio to measure how consistently teams documented anticipated outcomes before beginning work. In our Jira-based practice, every initiative and epic was expected to include an anticipated outcome.
The ratio helped us understand whether we were building the discipline of defining intended value. It didn’t tell us whether we ultimately realized that value.
With structured realization reviews, we can extend that measurement to include the percentage of reviews completed, the percentage due but still outstanding, and how long overdue reviews remain unresolved.
These measures should use initiatives whose scheduled reviews have become due, keeping those still within their observation periods separate.
We can also analyze actual results against anticipated outcomes. This differs from review completion. An organization might consistently complete its reviews while discovering that many investments fall short of expectations.
Together, these measures provide three useful perspectives: how effectively we deliver work, how consistently we define expected value before investing, and how well we follow through to evaluate that value.
Over time, the evidence can help us understand which investments achieve their intended results, where our assumptions are consistently optimistic, and whether we’re improving our investment decisions.
An illustrative realization dashboard
1. Feature Factory Ratio – Defining Anticipated Value
Objective: Measure and reduce the percentage of initiatives or epics that begin implementation without a clearly documented anticipated business outcome.
This metric helps determine whether the organization is consistently defining intended value before committing to delivery. It measures the discipline of documenting expected outcomes, not whether those outcomes were ultimately realized.
2. Initiative-Level Outcome Tracking
Anticipated vs. Actual Outcome
Compare the expected business result with the actual result to understand whether the investment achieved its intended value.
Is This Realistic?
Many organizations already struggle to maintain consistent planning, estimation, and delivery practices. Adding another expectation can create more work without necessarily improving decisions.
I wouldn’t start by requiring outcome reviews for every story or introducing another reporting process.
Instead, select one or two meaningful initiatives whose anticipated outcomes could influence future investment decisions. Identify an accountable business or Product stakeholder, establish the review date, and use an existing product or leadership discussion to evaluate the result.
Measurement and review require capacity. Someone needs to collect evidence, interpret it, and communicate the findings. Recognize that effort when planning the work, even if the review itself is lightweight.
Is this additional measurement just busywork? It could be, if we collect data to satisfy another reporting requirement. The value comes when we discover which investments achieve their anticipated outcomes, where our assumptions repeatedly fall short, and how that evidence can improve future decisions.
I’d start small and expand the practice only as it demonstrates value. If leadership isn’t using the findings to make better investment decisions, we should question the effort.
Closing the Loop
In Profitable Engineering, I describe Flow + Realization as complementary disciplines. Measuring delivery performance and business outcomes separately helps us understand both how effectively we deliver software and whether those investments produce their anticipated value. Together, that evidence helps us improve delivery performance and make better decisions about where to invest our limited capacity.
If we’re willing to measure how efficiently we deliver something, shouldn’t we be just as interested in whether it was worth delivering?
Update – October 18, 2026: Measuring Effectiveness Is Harder.
Following publication, Richard Beasley, a retired Rolls-Royce systems engineering professional, shared an observation that resonated with me: measuring efficiency is relatively easy; measuring effectiveness is far more difficult.
I’ve encountered this firsthand, including resistance to measuring outcomes from Product and Product Operations teams. I explored this challenge in my 2023 article, Outcome Metrics and the Difficulty of Reporting on Value. I returned to it in Profitable Engineering, where I wrote: “Organizations tend to fall back on output and delivery metrics, not because they matter more, but because they are easier to see.”
Measuring actual business impact can be genuinely difficult.
Benefits may take months to materialize, evidence may come from several systems or departments, and external factors can influence the results. Even when we observe an improvement, determining how much resulted from a particular initiative isn’t always straightforward.
Over time, some outcomes will be fully evaluated, others only partially understood, and some may remain unmeasurable with the available evidence. Documenting those findings has value too. We may discover recurring gaps in our data, assumptions, or measurement practices that can help us improve future investments.
That difficulty doesn’t mean we should avoid trying.
We should agree on the value the evidence will provide and whether the effort required to collect and interpret it is justified. Some investments warrant rigorous analysis; others may need only a simple review with acknowledged uncertainty.
Stakeholders should own their predictions, communicate confidence and uncertainty, and follow through on evaluating actual results. Achieving those outcomes often depends on contributions across the organization.
There’s also a human benefit. Documenting anticipated outcomes and connecting them to organizational goals helps teams understand why their work matters and how it contributes to something larger. This reinforces the sense of purpose Daniel Pink identifies as a key element of motivation, alongside autonomy and mastery. Sharing actual results gives teams a chance to see the impact of their efforts and learn from what happened, even when the original expectations weren’t met.
Even when the evidence is incomplete, we can learn something valuable about our investments, our ability to measure their impact, and the difference our teams are making. What matters is whether we use that learning to improve what we do next.
References & Further Reading
- Steve Pereira & Andrew Davis (2024). Flow Engineering: From Value Stream Mapping to Effective Action. IT Revolution. Book details – Practical mapping techniques for identifying constraints, improving flow, and aligning teams around outcomes.
- Daniel H. Pink (2009). Drive: The Surprising Truth About What Motivates Us. Riverhead Books. Book details – Explores autonomy, mastery, and purpose as key elements of motivation.
- Phil Clark (2026). Profitable Engineering: Transforming Technology Teams Into Strategic Business Partners. RYU Advisory & Media. Book website – Introduces Flow + Realization, connecting delivery effectiveness with measurable business value, including the Feature Factory Ratio and anticipated-versus-actual outcome measurement.
- Phil Clark (2026). Predictability vs. Outcomes: What Are We Actually Predicting? Read article – Explores applying forecasting discipline, confidence, and accountability to anticipated business outcomes, and comparing predictions with actual results to improve investment decisions.