Software Delivery Workflows: From Backlog to Production

There is no single universal workflow

A software delivery workflow is the sequence of states a piece of work passes through between “someone wants this” and “customers have it”. Whether it is configured in Jira, Linear, Azure DevOps, GitHub, GitLab or on a whiteboard, the workflow is the same idea: a shared agreement about what each stage means and when work may move on.

There is no single correct workflow. A two-person startup that deploys twenty times a day and a bank releasing quarterly under audit are both doing software delivery well when their workflow matches their constraints. The right workflow depends on:

• Team size — how many hand-offs happen, and between how many people.
• Release frequency — continuous deployment, weekly trains, or scheduled releases.
• Product risk — what a defect in production costs customers and the business.
• Regulatory requirements — whether approvals, segregation of duties or audit trails are mandatory.
• QA strategy — dedicated testers, developer-owned testing, or automated validation.
• Architecture — how independently parts of the system can be changed and deployed.
• Deployment automation — whether releasing is a button, a pipeline, or a coordinated event.
• Team ownership — whether one team owns work end to end or hands it to other teams.

This guide describes the common workflow models, what each one makes visible, and what each one costs — so you can choose the simplest workflow that still tells you what you need to know.

A common software delivery workflow

Many teams run some version of this development-to-production workflow. For each stage, it helps to be explicit about four things: why the stage exists, what happens there, what must be true before work leaves it, and what tends to go wrong.

Backlog

• Purpose: a list of ideas, requests and known work that may be done.
• Typical activities: capturing requests, rough prioritization, grouping into epics.
• Exit condition: someone decides the item is worth refining.
• Common risk: the backlog grows without pruning, and old items are mistaken for commitments.

Refinement

• Purpose: turn an idea into something a team can build.
• Typical activities: clarifying scope, acceptance criteria, design notes, splitting, estimating.
• Exit condition: the team understands the work well enough to start it.
• Common risk: refinement is skipped and questions surface mid-development, where they are far more expensive.

Ready

• Purpose: a queue of refined work the team can pull next.
• Typical activities: ordering, checking dependencies, planning the next sprint or cycle.
• Exit condition: someone starts the work.
• Common risk: “Ready” items that are not actually ready, which turn into blocked work once started.

Development

• Purpose: implementation is actively happening.
• Typical activities: coding, unit tests, local validation, technical changes.
• Exit condition: implementation is ready for review.
• Common risk: too much work started simultaneously creates excessive work in progress (WIP), so everything moves slowly.

Code Review

• Purpose: another engineer checks the change before it merges.
• Typical activities: pull or merge request review, discussion, requested changes.
• Exit condition: the change is approved and merged.
• Common risk: review queues grow quietly because reviewing competes with everyone’s own development work.

QA / Test

• Purpose: confirm the change behaves as intended and did not break anything.
• Typical activities: manual and exploratory testing, automated suites, regression checks, bug reports.
• Exit condition: the change passes validation.
• Common risk: testing becomes the constraint when development output exceeds validation capacity, or test environments are unstable.

Product Acceptance

• Purpose: the product owner or stakeholder confirms the change solves the problem.
• Typical activities: demos, acceptance against criteria, UX checks.
• Exit condition: the change is accepted.
• Common risk: acceptance waits for a meeting or a busy person, adding days with no work happening.

Ready for Release

• Purpose: finished work waiting to reach customers.
• Typical activities: release notes, bundling into a release, scheduling a deployment window.
• Exit condition: the change is deployed.
• Common risk: engineering-complete work accumulates here unseen, while reports already count it as done.

Production

• Purpose: customers can use the change.
• Typical activities: deployment, monitoring, feature-flag rollout, verification.
• Exit condition: none — this is delivery.
• Common risk: treating deployment as the end, without checking the change works in production.

Visualize the flow

Whatever the stage names, work moves through the same broad phases: an idea becomes ready, gets built, gets reviewed, gets validated, and is released. Work does not move at a steady pace. It moves quickly through some stages and waits in others — and those waiting points are where most delivery time goes.

Seven common software development workflows

The workflows below are common engineering workflow examples, ordered roughly from simplest to most controlled. None is universally better. Each one optimizes for different constraints.

1. Simple workflow

Small teams often start here because it costs almost nothing to run. There is one decision to make about each item — is someone working on it? — and nobody has to learn a process.

• Advantages: simple; low administrative overhead; easy to understand; few status transitions.
• Disadvantages: hides where work is actually waiting; cannot distinguish development from review or testing; weak bottleneck visibility; “Done” can become ambiguous.

Works well when: a small team owns implementation, testing and deployment, talks every day, and ships often enough that nothing waits long.

2. Development + review workflow

Teams that work through pull requests often add a review stage first, because review is where work most often waits for another person. With review as its own stage, a growing pile of unreviewed work becomes visible instead of hiding inside “In Progress”.

• Advantages: review bottlenecks become visible; the engineering workflow is clearer; fits pull-request-based teams naturally.
• Disadvantages: still hides testing and release; “Done” may still not mean production.

3. Development + review + QA workflow

This is common where QA is a distinct function, or where meaningful validation happens after development — integration testing, exploratory testing, test environments. It lets a team distinguish engineering work from validation work.

That distinction matters. When a QA workflow stage holds far more work than usual, it can reveal a delivery constraint: development is producing faster than validation can absorb. Without the stage, the same situation looks like “lots of work in progress”.

4. Full delivery workflow

A full delivery workflow follows work all the way to customers, which gives much stronger end-to-end delivery visibility.

• Advantages: identifies where work is waiting; distinguishes engineering completion from customer delivery; makes release lag measurable; better bottleneck detection; better executive delivery visibility.
• Disadvantages: more transitions; more workflow maintenance; teams must update statuses consistently; unnecessary stages create process overhead.

More statuses are not automatically better. Each one only helps if people keep it accurate and someone uses what it shows.

5. Continuous delivery workflow

In mature CI/CD environments, many manual stages disappear because automation handles them. A merged change is built, tested and deployed by a pipeline; nobody moves a ticket to “Ready for Release” because there is no waiting for a release.

• Automated tests replace most manual regression testing.
• Continuous integration keeps every change merged and verified.
• Deployment automation makes release a routine, low-risk step.
• Feature flags separate deploying code from releasing features to users.
• Monitoring confirms behaviour in production quickly.
• Rollback capability makes a bad change cheap to undo.

A short workflow here represents a very mature delivery process, not an immature one. It looks like the simple workflow on paper, but the controls still exist — they are encoded in the pipeline rather than in statuses.

6. Kanban / continuous flow

A kanban software development workflow organizes work as continuous flow rather than around sprint completion. Each stage has an explicit work-in-progress limit; when a stage is full, people help finish work downstream instead of starting more.

• WIP limits stop too much work being started at once.
• Cycle time — how long an item takes from start to finish — is the main speed measure.
• Throughput — how many items finish per week — replaces sprint velocity.
• Aging work — how long items have sat in their current stage — shows what is stuck.
• Queue size — how many items wait between stages — shows where flow is constrained.
• Flow efficiency — the share of elapsed time spent actively working — shows how much time is waiting.

Continuous flow is useful for support and platform teams with unpredictable demand, teams that release continuously, and teams whose work does not fit neatly into fixed iterations. Many scrum teams borrow WIP limits and aging without abandoning sprints; an agile development workflow does not have to pick one.

7. High-control / regulated workflow

Some environments legitimately need more stages: government systems, financial services, healthcare, and high-risk enterprise software where regulations or contracts require approvals, independent testing, security sign-off and a record of who approved what.

This does not mean every organization should adopt it. The trade-off is real: more controls can reduce certain operational and compliance risks while increasing coordination cost and delivery time. Every approval stage is also a queue.

Which workflow is better?

The best workflow is the simplest workflow that gives the organization enough control and visibility to deliver safely and predictably.

Different workflows optimize for different constraints. The table below compares them on what each one tends to make visible and what it tends to cost. These are relative, qualitative descriptions — not performance scores. A well-run simple workflow will outperform a poorly maintained full one.

Read the table as a set of trade-offs between three things: simplicity, visibility and control. Moving right on one usually costs something on another. Continuous delivery is the exception that proves the rule: it buys visibility and control through automation investment rather than through statuses.

Every workflow stage has a cost

Adding a workflow stage should provide meaningful information. A status generally deserves to exist when it represents a meaningful change in:

• Ownership — a different person or team is now responsible.
• Activity — a different kind of work is happening.
• Queue or waiting state — nobody is working on it, and it is waiting for someone.
• Validation — the work is being checked.
• Approval — someone must formally sign off.
• Release state — the change has, or has not, reached customers.

Avoid statuses that exist only because someone wanted another status. Compare:

“Development Complete”, “Waiting for Review” and “Ready for Review” usually describe the same situation: the code is written and nobody is reviewing it yet. One waiting state would say the same thing. Keep such distinctions only if they represent operational states the organization actually needs to measure.

Every additional state creates:

• another transition someone has to remember to make;
• another place work can wait;
• another status people must understand the same way;
• another opportunity for stale data.

The additional visibility should justify that cost.

Active work vs waiting: the difference that matters most

Many workflows fail to distinguish two very different situations: someone is actively working on this, and this is waiting for someone. Both look like “in progress”. Only one of them is progress.

A workflow such as Development → Ready for Review → Code Review → Ready for QA → QA makes the difference explicit. Development, Code Review and QA are active work. Ready for Review and Ready for QA are queues: the work is finished for now and waiting for the next person.

This matters because queue time often reveals more about delivery bottlenecks than active work time. In many teams, an item spends a few hours being reviewed and several days waiting to be reviewed. Speeding up the review itself would change little; shortening the wait would change a lot. Flow efficiency — active time divided by total elapsed time — makes this visible, and it is often surprisingly low.

Without waiting states, the best you can say is “15 issues are in QA”. With them, you can say “3 are being tested and 12 are waiting to be tested” — and those call for very different conversations. That distinction is at the heart of how VeloWise reads delivery: not just where work is, but whether it is moving. Aging work in progress and cycle time build on the same idea.

Done does not always mean delivered

In many workflows, “Done” means engineering has finished. It does not necessarily mean customers have the change. A typical path after development looks like: Engineering Complete → QA Complete → Approved → Ready for Release → Production.

Leadership needs to know the difference. “40 issues done” and “27 issues released” describe the same sprint, but one is an engineering story and the other is a customer story. If the gap is growing, finished work is accumulating somewhere between engineering and production.

Release lag is the time from engineering completion to production. Consistently long release lag points to release or deployment friction: infrequent release windows, manual deployment steps, approval queues, or environment problems. It only becomes measurable when the workflow separates “complete” from “released” — see the real outcome of a sprint for how this changes sprint reporting.

How workflow stages create bottlenecks

Every stage boundary is a hand-off, and every hand-off is a place work can pile up. The stage where work accumulates is usually where delivery slows down. Three common patterns:

Code review bottleneck

Sixteen items waiting against three in review may indicate that reviews are not prioritized over new development, that only a few people are able to review, or that changes are too large to review quickly. The counts alone do not say which.

QA bottleneck

A large queue before QA could mean testing capacity is short, test environments are unavailable, a batch of work arrived at once, or items are bouncing back to development. Each needs a different response.

Release bottleneck

Here the team is finishing work, but most of it has not reached customers. Engineering output and customer delivery can diverge for weeks when releases are infrequent or manual — and a sprint report counting “done” will not show it.

For a step-by-step method — comparing each queue with its own history and checking whether the work is aging — read how to find bottlenecks in software delivery. Unfinished work at the end of a sprint usually sits in these same queues, which is why bottlenecks and sprint carryover are so closely linked.

Workflow anti-patterns

Too few states

To Do → Doing → Done. Everything happens inside “Doing”, so bottlenecks are invisible until work is late.

Too many states

Fifteen to twenty-five statuses that nobody consistently maintains. The workflow looks precise, but the data describes what people remembered to click, not where work is.

Done before production

“Done” means engineering finished, but leadership reads it as shipped. Decisions are made on delivery that has not happened.

Statuses based on people

“With Bob” or “With QA person” ties the workflow to individuals. When people change roles, the workflow breaks, and queues become personal. Prefer delivery states (“Waiting for QA”) and use the assignee field for the person.

Statuses that are never updated

If items routinely jump from To Do straight to Done, or sit in Development long after they merged, every workflow metric becomes unreliable. A shorter workflow people actually maintain is worth more than a detailed one they do not.

Mixing priority with workflow

“Urgent” is not a stage of delivery. It is a priority or attribute. Moving urgent work into an “Urgent” status erases where it actually is.

Mixing blocked with delivery stage

Blocked can often be represented as an attribute or flag while the item keeps its underlying stage. “QA + blocked” tells you testing is where the blockage occurred; a generic “Blocked” column throws that away.

Workflow mapping: comparing different workflows

Different organizations name the same stages differently, and different tools encourage different vocabularies. One team’s “Peer Review” is another’s “PR”; “SIT”, “Verification” and “Testing” can all mean validation.

Normalizing each workflow into a small set of shared delivery stages — backlog, ready, development, code review, QA / validation, acceptance / approval, ready for release, released — is what makes delivery analysis possible across different workflows and different project-management platforms. Once a status is mapped to a stage, the same questions work everywhere: how much is in review, how long has it waited, how much is complete but not released? The methodology documents how VeloWise does this mapping.

How to design your workflow

Rather than copying a template, start from how work actually moves in your organization. Ask:

1. Where does work actually change ownership?
2. Where can work wait?
3. Where does validation happen?
4. What approvals are required?
5. When is engineering actually complete?
6. When does the customer receive the change?
7. Which queues would leadership want visibility into?
8. Which stages create meaningful delivery signals?

Then start simple. Add a stage only when it improves operational visibility or provides control you genuinely need — and remove stages nobody uses. A good test for any status: if you removed it, would anyone lose information they act on?

Workflow design also shapes planning. A workflow that hides queues makes sprints look more achievable than they are, because work waiting in review or QA is invisible at planning time. See how scope change affects outcomes and sprint commitment vs capacity for how this shows up in sprint commitments.

Try it: sketch your workflow

Use the workflow designer below to lay out your stages and mark each one as active work, waiting, complete or released. It gives simple, rule-based observations about what your workflow can and cannot show. Nothing leaves your browser, and no account is needed.

What should leadership look at?

• WIP by stage shows where work is concentrated today.
• Aging WIP shows which items have been in their stage much longer than usual.
• Queue time and stage duration show where elapsed time is spent — waiting or working.
• Cycle time shows how long work takes from start to finish, and how variable it is.
• Blocked time shows how much delay comes from dependencies and impediments.
• Throughput and carryover show how much finishes, and how much keeps moving to the next sprint.
• Engineering complete, ready for release, released and release lag show whether finished work reaches customers.

The point is not to watch every metric. Workflow data becomes valuable when it helps explain why delivery outcomes are changing — why a sprint missed, why carryover grew, why releases slowed. For a leadership-level set, see sprint health metrics and the delivery metrics leadership actually needs.

How VeloWise reads your workflow

Different teams use different workflows. That is why VeloWise does not assume that a status called “Done”, “QA” or “Complete” means the same thing everywhere. It maps your organization’s actual workflow into normalized delivery stages, so it can analyze:

• where work accumulates;
• how long work waits;
• where carryover originates;
• whether engineering-complete work reaches production;
• where delivery flow changes over time.

You keep your workflow. VeloWise reads it.

Frequently asked questions

What is a software delivery workflow?

The sequence of states work passes through from idea to production — for example backlog, development, code review, QA, ready for release and released — together with an agreement about what each state means and when work may move on.

What is the best software development workflow?

There is no universally best workflow. The best one for a team is the simplest workflow that gives enough visibility and control for the way it actually delivers software. A small autonomous team and a regulated enterprise should not necessarily use the same one.

How many workflow statuses should a team have?

As few as give you the information you act on. Each status should represent a real change in ownership, activity, waiting, validation, approval or release state. Many teams land between five and nine; mature continuous-delivery teams often have fewer.

Should “Blocked” be a workflow status?

Usually it works better as a flag on the item, so the item keeps its real stage. “QA + blocked” tells you where the blockage happened; a generic Blocked status does not.

What is the difference between active and waiting stages?

Active stages mean someone is working on the item (development, review, testing). Waiting stages mean it is queued for the next person (ready for review, ready for QA, ready for release). Separating them shows how much delivery time is spent waiting, which is often where bottlenecks are.

Is a scrum workflow different from a kanban workflow?

The stages can be identical. Scrum organizes work into sprints with a commitment at the start; kanban manages continuous flow with work-in-progress limits. Many teams combine them, for example sprints with WIP limits and aging.

Related guides

• How to Find Bottlenecks in Software Delivery

  Work accumulating in review or QA — and staying there — shows where delivery slows down. Compare queues with their history and look at aging.

• Why Work Carries Over Between Sprints

  Carryover is not automatically underperformance. Where work was at sprint close — and how long it has been carrying — shows what to change.

• How to Measure the Real Outcome of a Sprint

  Completed vs not completed hides most of a sprint’s story. Measure commitment, scope change, engineering completion, QA and release together.

• Sprint Health: Metrics That Help Explain Whether Delivery Is on Track

  Sprint health is several signals, not one score: commitment, scope growth, progress, carryover, stage distribution, aging, blocked work and release.

• How Scope Changes Affect Sprint Outcomes

  Work added mid-sprint changes what a completion rate means. Track original commitment and final scope together to explain the sprint outcome.

All engineering delivery guides