Engineering Delivery
Flow
New to DORA? Start with What is DORA?, then come back here.
Flow is how smoothly work moves through a team, from someone picking up a task to it reaching customers. Most work spends far more of its life waiting than being worked on, and the measures on this page show where it waits. They read from your work tracker, such as Jira or Linear, and from your code host, and they complement the five DORA metrics, which start only once code is written.
The Flow page shows how tickets move through your team: how much is in flight, where it waits, what is stuck and how long a whole piece of work takes to reach customers. You find it under Delivery, as the Flow tab. This guide explains everything on the page, what each reading means and what to do about it.
What the Flow page shows
At the top, the Flow update says how much is in flight right now and how long the oldest item has waited, for example "24 tickets are in flight right now, and the oldest has been in review for 9 days." With no work tracker connected it says "Connect your work tracker to see how work moves. Nothing is estimated."
The tiles are Time to first review and Median change size (explained on Review), Work in progress, Done per week, Changes with no ticket and Ticket to customer, each explained below. Directly under the tiles, Where the work went splits the changes merged in the period by work type; see Where the work went. Then the charts, in three groups:
- Where work piles up: In flight right now, by stage shows "Tickets in each stage at this moment, not an average over the period", and Done per week shows tickets finished a week, by month: "Steady matters more than high."
- Stuck now: Longest in their status lists the tickets in progress, in review or in testing that have sat longest in the status they are in now. See Stuck work.
- Where the time goes: Time in each stage shows the median time finished tickets spent in each stage. See Days in each stage.
Every bar opens its tickets, by id and team, never by person.
What flow means and why it matters
Good flow means work moves steadily from start to finish with little waiting, so a team can finish what it starts and make promises it keeps.
Think of a team's work as a series of stages: a task is in progress, then in review, then in testing, then done. At each stage it can either move on or sit and wait. The whole path, from idea to customer, is called the value stream. DORA's capability visibility of work in the value stream is about being able to see that path clearly, because you cannot speed up waiting you cannot see.
There is a simple rule behind most of this page. The more things a team works on at once, the longer each one takes, because every item started competes for the same people's attention. Queueing theory calls the relationship Little's law; you do not need the maths to use it. If the booking team below has 24 tasks in progress and finishes about 12 a week, a new task joining the back of that pile can expect to take around two weeks. Start fewer, and each finishes sooner.
Throughout this page we follow a fictional team of six engineers who build an online booking app and track their work in Jira.
Note: Some measures here are a snapshot of right now, such as work in progress and stuck work. Others are a figure for a period, such as done per week and time in each stage. A snapshot does not change when you pick a different period; a period figure does.
Work in progress
Work in progress is the number of tasks a team has started and not yet finished, right now.
What it is
Every ticket that is in progress, in review or in testing counts. The glossary entry for work in progress (WIP) gives the short version. It is a point in time: it tells you how much is open today, not how much was done last month.
Why it matters
Every item started and not finished waits on all the others. DORA's work in process limits page puts it bluntly: when faced with too much work and too few people, "rookie managers assign people to work on multiple tasks in the hope of increasing throughput. Unfortunately, the result is that tasks take longer to get done, and the team burns out." Starting less is the surest way to finish more.
How to read it
Look at it per engineer as well as in total. The booking team has 24 tickets in flight for 6 engineers, which is 4 each. Nobody can actively work on four things at once, so most of those tickets are waiting.
What good looks like
No published source gives a figure. Compare with your own past, and watch the trend: work in progress that keeps rising while done per week stays flat means work is piling up.
How to improve it
DORA's work in process limits guidance has three steps:
- Make the work visible. Put every piece of work on a board, including the invisible work like support requests and small favours.
- Set limits based on capacity. Give each stage, or the team as a whole, a maximum number of items, matched to the people available.
- Pull, do not push. New work only starts when something moves on and frees a slot.
Day to day, that means finishing or handing over before starting something new, making blocked work visible at standup, and looking at the tickets in flight longest first.
Common mistakes
DORA lists these pitfalls:
- Overlooking invisible work. If the board only shows planned features, the limit is fiction.
- Setting limits too high. If people still split their time across several tasks, the limit needs to come down.
- Relaxing the limit when people look idle. A free moment is the time to help finish someone else's work, not to start new work.
- Never tightening it. When the limit becomes easy, lower it further to expose the next problem.
How Solidafy measures it
The tickets in progress, in review or in testing right now, under your status to stage mapping in Settings, with the number per engineer of the mapped teams. Jira issues reported by an app account are left out. The Team health section shows work in flight per engineer by team, for teams shown on their own (3 engineers or more by default, set in Settings), as a check on load, never a score.
Done per week
Done per week is how many tickets the team finishes in a typical week.
Why it matters
Steady output is what lets a team plan and make promises it keeps. It is the tracker's view of throughput: how much work moves through the system in a given time.
How to read it
Look for steadiness, not height. The booking team finishes between 10 and 14 tickets most weeks. A sudden drop to 4 is worth a question: was the team pulled onto an incident, or is work stuck? A rise is not a target. Tickets come in all sizes, so splitting the same work into more tickets raises the number without delivering anything more.
What good looks like
No published source gives a figure. Compare with your own past.
How to improve it
Done per week usually improves as a side effect of lower work in progress and shorter waits, rather than by pushing on it directly.
How Solidafy measures it
Tickets that reached done in the period you choose, per week, compared with the period you compare against. Jira issues reported by an app account are left out.
Days in each stage
Days in each stage is how long finished tickets spent, at the median, in each stage: in progress, in review and in testing. On the Flow page it is the Time in each stage chart.
Why it matters
Work spends most of its life waiting. The stage where tickets sit longest is where a team gains most by looking. Time in a stage is a form of cycle time, the time a piece of work takes once someone starts it.
How to read it
Each tracker has its own status names, so Solidafy maps your statuses to five stages in Settings: backlog, in progress, review, testing and done. That mapping lets the app compare stages across teams that name their columns differently.
Read the median, the middle value, so one ticket that sat for months does not distort the picture. In the booking team, finished tickets spent a median of 2 days in progress, 3 days in review and half a day in testing. Review is the longest stage, which matches what they see in code review.
What good looks like
No published source gives a figure. Compare with your own past, and start with the longest stage.
How to improve it
Look at the stage with the longest median first, then open the tickets that spent longest there and ask what they were waiting for. This is the same "find the biggest constraint" idea described in Improving software delivery.
Common mistakes
- Moving tickets between columns late, all at once, so the history no longer shows where time went.
- A mapping that leaves out a status the team uses, so time in it is lost.
How Solidafy measures it
For the tickets finished in the period you choose, the median time each spent in progress, in review and in testing, read from the tracker's status history and your status to stage mapping. Every stretch a ticket spent in a stage counts, also after it was reopened. Jira issues reported by an app account are left out.
Stuck work
Stuck work is the tickets that have sat in the same status for a long time and are still open.
Why it matters
A ticket that sits in one status for days is often blocked or waiting on someone. Seeing it early is cheaper than finding it at the end of a sprint.
How to read it
Sort by how long each ticket has been in its current status, longest first. The booking team has one ticket that has been in review for 9 days and two in progress for over a week. Those are the first things to talk about at standup.
There is no universal line for "stuck". Solidafy's standup view treats a ticket as stuck once it has been in one status for more than 3 days, and treats a change waiting more than 72 hours for review as stale. Use those as a starting point and adjust to your team's rhythm.
What good looks like
No published source gives a figure. Fewer stuck tickets than last period, and none that nobody has noticed.
How to improve it
- At standup, ask what each of the longest-stuck tickets needs to move.
- Make blocked work visible instead of quietly working around it.
- If tickets keep getting stuck in the same stage, that stage is your constraint.
How Solidafy measures it
The tickets in progress, in review or in testing, longest in their current status first, from the tracker's status history and counted to the end of the period you choose. A ticket whose history does not reach its current status is left out, and so are Jira issues reported by an app account. The Open work section also lists everything open that is not moving, pull requests included.
Ticket to customer
Ticket to customer is how long a piece of work takes from the ticket starting work to the deploy that ships it to customers.
Why it matters
Change lead time, one of the five DORA metrics, starts when code is committed. Real work often starts earlier, with investigation, design or waiting for answers, and often involves several changes. Ticket to customer starts when the ticket moves into work, so it shows how long the whole piece of work takes to reach people.
How to read it
Compare it with change lead time. In the booking team, the median change takes 5 days from first commit to production, but the median ticket takes 11 days from starting work to shipping. The gap is time before the first change, or time spent across several changes for the same ticket.
What good looks like
No published source gives a figure. Compare with your own past.
How to improve it
Open the tickets that took longest and see where the time went: before the first change, or after it. Time before the first change often means unclear requirements or tickets that are too big. Time after it usually means the review and deploy waits covered elsewhere on this page.
How Solidafy measures it
The median, over the tickets shipped in the period you choose, of the time from the ticket starting work to the deploy that shipped the last change that names it. A ticket with a change still open or not yet deployed has not shipped, and a ticket the tracker never marks as started has no start, so both are left out.
Changes with no ticket
Changes with no ticket is the share of merged changes that do not name any ticket from your tracker.
Why it matters
A change that names no ticket is work nobody planned or tracked. A rising share means more work is arriving outside the plan, such as urgent fixes and small requests, or that the team links less. Either way, it is work you cannot see on the board, which makes flow measures less accurate.
How to read it
In the booking team, 18 of 120 merged changes name no ticket, which is 15%. Open them: some will be dependency updates or typo fixes that never needed a ticket, others will be real work that should have been planned.
What good looks like
No published source gives a figure. Compare with your own past.
How to improve it
- Agree a habit of putting the ticket key in the branch name or the change title.
- Look at the unlinked changes for work that should have been planned, and plan it next time.
How Solidafy measures it
The share of changes merged in the period you choose whose title, branch, description or commits name no ticket that the connected tracker holds. A key is matched whatever its case, and a string that looks like a key but that the tracker does not hold, such as UTF-8, is never treated as a link. It is only read where a code host and a tracker are both connected, and changes opened by bots are left out.
Where the work went
Where the work went splits the changes merged in the period by work type, as one bar: features, bug fixes, chores and other. Choose a part to see its changes and its split by team.
Why it matters
Time spent fixing and maintaining is time not spent on what customers asked for. Seeing the split lets a team decide whether it is the split it wants.
What good looks like
No published source gives a right split. It depends on what the business needs now. Agree a split as a team and check it here.
How to improve it
Agree the split you want first. Then open other to see which changes say nothing about their type, and name them better.
How Solidafy measures it
Every change merged in the period you chose, by its work type. A chore is upkeep, such as refactors, dependencies, build, CI, docs and tests. Other is a change nothing describes.
A change takes its work type from the tickets it names (their type, labels, project or team), else its own pull request labels, else the first word of its title (feat:, fix:, chore:), else the first part of its branch (feature/, bugfix/). It is other when none says. The words that map to each type are rules every install starts with, covering the names Jira, Linear and GitHub ship with.
Jira gives the issue type, labels and project. Linear gives labels, the project and the team. GitHub and GitLab give pull request labels. Every code host gives the title and branch prefix. Jira components and a sub-task's parent type are not read yet. A team smaller than the smallest team shown on its own (3 engineers by default, set in Settings) is not shown on its own, and changes opened by bots, such as Dependabot, are left out.
Questions the app raises
Work in progress keeps going up. What should we do?
More is being started than finished, so every item waits longer. Stop starting and start finishing: at standup, look at the tickets in flight longest first and ask what each needs to move. Agree a limit on how many items the team has in progress at once, and pull new work only when something finishes. If done per week is flat while work in progress rises, work is piling up, not getting done faster. See Work in progress.
Done per week dropped. Is the team slower?
Not necessarily. Tickets come in all sizes, and one large ticket can look like a slow week. Ask what happened: an incident, holidays, a big ticket, or work stuck waiting. Look at Longest in their status for stuck work. A rise is not a target either; splitting work into more tickets raises the number without delivering more.
One stage takes far longer than the others. Where do we start?
Start there. Open that stage in Time in each stage to see the tickets that spent longest in it, and ask what they were waiting for. If it is review, the Review page shows whether changes wait for a reviewer. If it is testing, look at what makes testing slow or manual. This is the same idea as finding your biggest constraint.
The update says the oldest ticket has been in review for days. Is it stuck?
Probably. A ticket that sits in one status for days is often blocked or waiting on someone. Raise it at the next standup. The standup view in Meetings treats a ticket as stuck after more than 3 days in one status.
Ticket to customer is much longer than change lead time. Why?
Change lead time starts at the first commit; ticket to customer starts when the ticket starts work. A big gap means time is spent before anyone writes code, such as unclear requirements or waiting for answers, or that a ticket needs several changes. Open the tickets that took longest and see where the time went.
The numbers look wrong for our board. Why?
Flow reads your tracker's statuses through the status to stage mapping in Settings. A status mapped to the wrong stage, or not mapped at all, moves time to the wrong place or loses it. Check Statuses and stages in Settings; see Setting it up.
A tile says it is not measured. Why?
Flow needs a connected work tracker, such as Jira or Linear. Changes with no ticket needs a code host and a tracker connected together. See Setting it up.
Learn more
Official sources:
- DORA capability: work in process limits
- DORA capability: visibility of work in the value stream
- DORA capability: visual management
- DORA value stream management guide
Related Solidafy guides: