Software delivery
Understand your whole software delivery system.
See where work waits, what actually affects delivery time, how predictable your system is, and what you can realistically commit to.
The whole system
Software delivery doesn't start when coding starts.
Follow work from Requested through Waiting for prioritization, Ready for development, Development, Code review, Testing, Approval, Waiting for release, and Delivered. The full path is the delivery system.
- Requested
- Waiting for prioritization
- Ready for development
- Development
- Code review
- Testing
- Approval
- Waiting for release
- Delivered
Customer request to production: more than three months
Development to production: 5 days
You can make your delivery metrics look a lot better without actually improving delivery.
Just start the clock later.
Imagine a customer asks for something in January. It sits in the backlog for three months, development starts on April 10, and five days later it’s in production.
How long did it take to deliver?
- Five days?
- Or more than three months?
Sonya Siderova Founder, NaveWhere did you start the clock?
The measurement boundary determines what the metric can tell you. Starting the clock at development measures development onward. Starting at the customer request measures the full time the customer waited.
- Lead Time
- How long work takes from a defined request or commitment point to delivery.
- Cycle Time
- How long work takes through the part of the workflow you’re measuring.
The important thing is to define where each clock starts and stops.
Local optimization
Optimizing one part doesn't optimize the system.
If coding becomes 50% faster but accounts for only 10% of total customer lead time, the effect on total delivery time is limited. The rest of the time still exists.
Before
After coding becomes 50% faster
Total customer lead time: 5% shorter
WHERE THE REMAINING TIME GOES
Work and wait
Active effort and idle time contribute differently to total delivery time.
Queues
Work accumulates before the next activity can begin.
Handoffs
Each transfer can add waiting before work continues.
Dependencies
Work can pause until another team, system, or decision is ready.
Approvals
Work waits when a required decision is unavailable.
Release constraints
Finished work can still wait for a release opportunity.
The question isn't only “How quickly are developers working?” It is “Where is the work spending its time?”
AI can make work faster in one part of delivery without shortening the whole system. The same question applies: Where is the work spending its time?
Measure flow efficiency Break down Cycle Time See AI in software delivery
Flow metrics
Measure the system with flow metrics.
Four numbers tell you a lot about a delivery system. Their relationship matters more than treating them as four independent KPIs.
Work in Progress
How much work has been started but not finished?
Throughput
How much work is being completed?
Cycle Time
How long does work take to move through the system?
Work Item Age
How long has unfinished work already been in progress?
Why Work in Progress rises
When work arrives faster than it finishes, Work in Progress grows. That is where the chain below begins. In a stable system, Little's Law relates WIP, throughput, and cycle time.
- Work in Progress rises
- More work waits
- Work Item Age rises
- Cycle Time can eventually rise
- Throughput may remain unchanged
Read these metrics together. The goal is to understand how the delivery system behaves, not to build a dashboard of isolated numbers.
Delivery variation
Variation is part of software delivery.
Your work doesn't take the same amount of time every time. Most items may cluster within a range, while some take much longer.
The average
An average describes past work. It does not promise an outcome.
The variation
The spread shows how consistently the system delivers.
The percentiles
Percentiles show how delivery times are distributed across completed work.
The outliers
Unusually long items can reveal conditions worth investigating.
The 50th percentile is the time within which 50% of items finished. The 70th, 85th, and 95th percentiles show the same threshold for increasing shares of completed work.
Waiting time
Find where the time actually goes.
Waiting is often where the opportunity is. Breaking Cycle Time down by process state shows whether time is going into active work or queues between activities.
Almost two thirds was waiting
Across 241 items, work had spent 919 days in Ready for Deployment. That state accounted for 32% of total delivery time, while Ready for Testing accounted for another 30%. Deployment happened once every two weeks. Deploying as soon as work was ready could reduce delivery time by around 30%, without extra people, new tooling, or pressure to work faster. Sometimes the biggest opportunity is sitting in a place where nobody is doing any work at all.
“How do we make developers faster?”
“Why is work waiting here?”
A team working with Joelma Castro appeared slow in development. The data showed that waiting accounted for 77% of its Cycle Time.
Aging work
Finished work tells you what happened. Aging work tells you what is happening.
Completed item
Cycle Time: 23 days. The result is known, but that item cannot be helped.
Current item
Age: 16 days and already above the historical 85th percentile. The team can still act.
Aging makes delivery data useful during the work, not only afterward. Teams can see which items are taking longer than similar completed work, investigate blocks or dependencies, and decide what needs attention before delay becomes a completed result.
Meaningful signals
Not every metric movement deserves an intervention.
Delivery metrics move all the time. Suppose Cycle Time went from 17 to 21 days. Did the system change? Maybe. Maybe not.
Some movement is normal variation. A meaningful signal suggests that the system may be behaving differently. Reacting to every change creates unnecessary interventions and makes it harder to learn which actions actually affected performance.
Detect
Did something meaningfully change?
Investigate
What is driving the change?
Intervene
Make a targeted change.
Measure
What happened afterward?
MOVEMENT WITHIN ITS NORMAL RANGE
Predictable delivery
Fast isn't the same as predictable.
Team A: 4, 7, 29, 5, 42, 8 days. Team B: 10, 12, 11, 13, 10, 12 days. Fast results alone do not make delivery predictable.
Team A
Team B
Which system is easier to make commitments from?
Team A sometimes delivers much faster, but its results vary widely. Team B takes longer at its fastest, yet its results stay within a much tighter range. That makes Team B easier to reason about.
Stable doesn't mean good. Stable means predictable.
First understand what the system can reliably do. Then decide whether that performance is acceptable and where improvement is needed.
Doodle moved from story point estimates to no estimates with Nave in less than six months.
Read the storyProbabilistic forecasting
Stop turning uncertainty into a single date.
Leadership asks, “When will it be done?” A single date says November 14. Historical performance gives a range: 50% by Nov 4, 70% by Nov 9, 85% by Nov 14, and 95% by Nov 22.
The single-date answer
November 14
The probabilistic answer
- 50%Nov 4
- 70%Nov 9
- 85%Nov 14
- 95%Nov 22
The uncertainty already exists. A probabilistic forecast makes it visible.
- How much can we deliver by this date?
- When can we deliver this amount of work?
More than 200 teams at Nubank use Nave. The published story focuses on its Global Productivity Team and productivity at scale.
Read the storyBeyond teams
Customers experience services, not Jira boards.
A software service may require an API team, a mobile team, a web team, and a platform team, possibly working in different tools. Understanding delivery means seeing how work moves across them.
Teams
API team
Mobile team- Web team
- Platform team
Service
One software service
Portfolio
All services together
Improving every team individually does not necessarily optimize the service they collectively deliver.
Analyze services and portfolios
Across more than 30 teams, United Cloud compares current performance with the past month, three months, and six months to sustain efficient operations at scale.
Read the storyTwo decision levels
Delivery improvement needs evidence at two levels.
Teams need to manage aging work, queues, blocks, and what to finish next. Leadership needs evidence on predictability, improvement, capacity, priorities, and realistic commitments.
Team decisions
- Where is work aging?
- Where are queues forming?
- What is blocked?
- What should we finish next?
Leadership decisions
- Is delivery becoming more predictable?
- Are improvements showing up in the data?
- Where does attention need to go?
- Where is delivery capacity going?
- What can we realistically commit to?
Same system. Different decisions.
Across more than 60 teams, Ramsey Solutions achieved over 60% flow efficiency and reduced work in progress by more than 20%, from 620 to 480 items, in 22 weeks.
Read the storyDelivery evidence
From delivery activity to delivery evidence.
This progression connects day-to-day delivery activity with stronger system decisions and evidence leadership can use.
- See what changed
- Understand why
- Decide what to do
- Measure what happened next
Explore further
What do you want to improve?
Start with the delivery problem you need to understand, then use the relevant analysis to investigate it.
Flow is slow
Work keeps getting stuck
Delivery is unpredictable
Metrics changed without a clear reason
Leadership needs visibility
FAQ
How should you measure software delivery?
On this page, software delivery is the system through which work moves from demand to delivery. The measurement boundary can include the full path from a customer request to production, not only development.
Lead Time is how long work takes from a defined request or commitment point to delivery. Cycle Time is how long work takes through the part of the workflow you’re measuring. The important thing is to define where each clock starts and stops.
The core flow metrics are Work in Progress, Throughput, Cycle Time, and Work Item Age. Together, they show how much work is underway, how much finishes, how long finished work took, and how long unfinished work has been underway. No one measure answers all four questions.
DORA’s lead time for changes measures from code commit to production. Flow metrics such as Work in Progress, Throughput, Cycle Time, and Work Item Age describe how work moves within a chosen measurement boundary. Commit to production is one such boundary. Demand to delivery is a broader one.
Start by measuring the whole system, not one part. Use percentiles to see variation, inspect where work waits, monitor aging work, and distinguish a signal from normal variation before intervening. Then measure again. Stable performance is predictable, but stability alone does not mean the performance is good.
Use a probabilistic forecast based on historical delivery performance and express the answer as percentile ranges. A range makes the existing uncertainty visible instead of presenting one date as certain.
Make software delivery predictable.
Use Nave to understand delivery behavior, improve the system, and show leadership what changed.