“Where is work waiting, and is delivery getting faster?”
Every flow metric — velocity, time, load, efficiency, distribution and predictability — and all five DORA delivery metrics, on one model with the value streams, the funded work and the cost behind them. Dotwork reads them from the delivery data you connect: work items and their status history from Jira, Azure DevOps or Linear, pull requests from GitHub, and the deployment and incident records you bring in from your pipeline and incident tools. Map your own workflow states and work types once. When DORA changes a definition, past readings keep the one they were measured with. And read delivery beside OKRs, the lean portfolio and TBM — not in a dashboard only engineering opens. Dot explains why a number moved; engineering leaders decide what to change.
The pressure
Flow and DORA metrics usually live in an engineering dashboard the rest of the business never opens. Lead time is up, but nobody can say which value stream it hurts, which funded bet is waiting or what the waiting costs. The portfolio review runs on status reports, while the evidence of where work actually waits sits one tool away.
What it looks like today
Full coverage
Flow items, flow metrics and DORA’s five measures, each computed from the delivery data you connect and read beside the portfolio, the budgets and the strategy.
Built for the Flow Framework and DORA’s five metrics, as of the 2025 research
Kersten’s four kinds of work.
How value moves through each value stream.
How quickly changes reach production.
How often changes go wrong.
Beyond commit to deploy.
What the research says drives the numbers.
What changes
Metrics in an engineering-only dashboard
Flow and DORA beside the value streams, funded work and cost they serve
Commit to deploy, and nothing either side
Flow measured from intake to outcome, with the waiting made visible
Story points and velocity charts
Flow items counted the same way across every team and tool
A number moved and nobody knows why
Each movement read beside incidents, staffing, dependencies and priority changes
Flow, with the money beside it
Pick a value stream and read its flow from the work itself: velocity, time, load and efficiency, with flow time split by stage into active and waiting, so the stage where work sits idle stands out. Flow distribution shows which kind of work crowded out the features. The DORA metrics sit underneath, and the value stream’s budget and plan sit beside it — so a long wait in review becomes a capacity or funding decision, not a retro comment.
Where other tools stop
Engineering metrics tools measure delivery in depth. They rarely hold the plan of record, the value stream budget or the portfolio decision a delay affects.
Flexed to how you run
No two teams use the same workflow, and most companies run more than one delivery tool. Dotwork maps what you already have to the standard definitions once, so the numbers compare without asking teams to change how they work.
Your states, mapped once
Mark which workflow states are active, waiting or done. Flow time and flow efficiency read from your definitions, and the mapping is visible to everyone.
Your work types
Map issue types to features, defects, risks and debts — or add your own — with the four flow items kept underneath for comparison.
Any mix of tools
Teams on Jira, Azure DevOps, Linear and GitHub measured on one set of definitions, without moving anyone’s work.
Team, value stream or portfolio
Read the same metric for one team, a value stream or the whole portfolio, rolled up through the hierarchies the portfolio already uses.
When DORA redefines a metric
DORA’s metrics have been renamed, redefined and extended since the original four keys, and the research will keep moving. Dotwork keeps each metric’s definition with its readings, proposes how your measures move when a definition changes and keeps past readings under the definition they were measured with.
Time to restore service redefined as failed deployment recovery time (2023)
Recovery measured for change-caused failures only; earlier readings keep their definition
Deployment rework rate added as a fifth metric (2024)
Added from the deployment records you already connect
Metrics regrouped as throughput and instability (2024)
Views regrouped; every reading stays where it was
An AI capabilities model and seven team profiles in the 2025 research
The seven capabilities assessed in Maturity; delivery read beside team context
Flow predictability added by SAFe 6.0 as a sixth flow metric
Available beside Kersten’s five, shown only where you run it
Every framework, one model
Delivery metrics say whether work is flowing. The portfolio says which work was funded, OKRs say what it should move and TBM says what it costs. Because they share records, a slower value stream shows up next to the funded work and key results it holds back.
Funding value streams, not projects
Flow per value stream beside its budget and the epics drawing on it.
Explore Lean Portfolio ManagementScaled Agile’s operating model for AI
The SAFe flow metrics read from the same delivery data as the increments.
Explore AI-Native SAFeGoals tied to funded work
Delivery metrics set as key results, or read beside the key results the work serves.
Explore OKRsTeams funded around products
Each product team’s flow beside what the product costs and earns.
Explore Product Operating ModelIT spend taxonomy
What each value stream costs to run, from TBM’s allocation.
Explore TBMASC 350-40 · ASU 2025-06 · IAS 38
The work items behind the flow metrics are the evidence capitalization draws on.
Explore Software CapitalizationAI-native flow and DORA
Delivery metrics without context mislead. Dot reads each movement beside what else happened — incidents, staffing, dependencies, priority changes — and drafts the explanation. Every finding stops at the engineering or portfolio leader who owns the decision.
Reads flow load and aging work across teams and value streams, and calls out items sitting in a state far longer than usual.
Splits flow time into active and waiting time by state, and names the states where work waits longest in each value stream.
Reads a movement in flow or DORA metrics beside the incidents, staffing changes, dependencies and priority shifts in the same period, and drafts the likely reasons.
Proposes which flow item each issue type and workflow state maps to, with a confidence score.
Ranks unusual movements in delivery metrics against their trend, so the review starts with what changed.
Tracks dependencies between teams and flags the ones adding waiting time to funded work.
Compares your measures with a changed definition and proposes how each one moves, with past readings left as they were.
Drafts the delivery readout for the portfolio review — flow by value stream, DORA trends and the funded work each one affects.
Where it runs in Dotwork
Dotwork does not ask you to adopt a new method. The framework becomes a view over the same model these solutions already read and write.
How it compares
Engineering intelligence platforms measure delivery in depth, straight from Git and the pipeline. Spreadsheets and BI join it to everything else by hand. Flow & DORA on Dotwork reads the same measures from connected delivery data and puts them beside the value streams, budgets and goals they serve.
| Capability | Engineering intelligence platforms | Spreadsheets & BI | Flow & DORA on Dotwork |
|---|---|---|---|
| Flow velocity, time, load, efficiency and distribution | Partly | ||
| The five DORA delivery metrics | Partly | ||
| Native instrumentation of Git, CI/CD and incident tools | Partly | ||
| Flow from intake to outcome, not just commit to deploy | Partly | ||
| Flow read from your own states and work types | Partly | ||
| History kept across DORA’s definition changes | Partly | ||
| Delivery beside the portfolio, budgets and value streams | Partly | ||
| Cost per value stream from the reconciled ledger | Partly | ||
| Movements explained and readouts drafted for review | Partly | ||
| OKRs, lean portfolio and TBM on the same records |
Who it is for
“Is delivery getting faster — and where is work waiting?
“Is our lead time up because of us, or because of what we are waiting on?
“Which funded bets are held up by waiting work?
“What does the waiting cost, and in which value streams?
“Which capabilities would move our delivery numbers most?
“Is the money we put into delivery making it faster and safer?
Before you buy
How to get a number instead of a pitch.
1
Good answer · The change, deployment and incident records you connect — with each definition visible.
Bad answer · A score the vendor computes and can’t explain.
2
Good answer · The epics, their budget and the key results they serve, from the same view.
Bad answer · An export for someone to join in a spreadsheet.
3
Good answer · Past readings keep the definition they were measured with, and the change is shown.
Bad answer · History is recalculated silently, or the chart starts over.
Strategy & Delivery
The methods that turn strategy into funded, delivered work.
The model underneath
Steer, Fund & Optimize and Govern & Deliver all read and write the same Enterprise Operating Model. The first module you license builds the model. Every module after it adds context instead of another silo — and Dotwork AI reads all of it, stopping where the decision is yours.
See the Enterprise Operating Model© 2025-2026 Dotwork, Inc. All rights reserved.