# How to fix task bottlenecks: 65% wait-state ratio plus median cycle time

Priya Nandakumar · October 30, 2026

> Fix task bottlenecks with a 65% wait-state ratio and 2026 median cycle time to choose automate or defer, without relying on published benchmarks.

This guide uses a 65% wait-state ratio and 2026 median cycle time to decide between automate or defer.

It applies that rule to task bottlenecks without relying on a published benchmark.

![This guide uses a 65% wait-state ratio and — How to fix task bottlenecks](https://static.mm-ais.com/article-images-ai/how-to-fix-task-bottlenecks-65-wait-stat-ai-4cb343ea.jpg)

## What a wait-state ratio actually measures

A wait-state ratio is wait-time divided by total cycle time: it measures how much of an item's elapsed life is spent not being worked. That differs from a utilization-based bottleneck definition, which identifies the busiest or most constrained resource, such as a station whose daily capacity is lower than the next station's.

Nulab defines a bottleneck as "any situation where work is delayed." Its cabinet line shows the capacity view: a cutting station processes 50 panels per day while assembly can handle 70, so unfinished panels pile up. That mismatch identifies a constrained station, but the wait-state ratio shows where the delay actually lives in time. To compute it, pull wait timestamps from your board tool's state transitions rather than estimating from memory.

| State | In numerator? |
| --- | --- |
| Queued (waiting to start) | Yes |
| Active (someone working) | No |
| Blocked (waiting on an external party) | Yes |
| Review | No |

The ratio aggregates queued plus blocked time and divides by total cycle time, the elapsed time across all four states. A resource can be highly utilized while items still spend most of their cycle in queued or blocked time, so the ratio and utilization can disagree.

For each item, record entry and exit timestamps for queued and blocked, sum those durations, and divide by the item's entry-to-exit cycle time. Active and review time stay in the denominator because they are part of elapsed cycle time, even though they are not wait time. Run the calculation over one sprint for the queue you are examining.

Use the ratio as a time-based diagnostic, not as a capacity label. If your board does not record state-transition timestamps, the ratio cannot be computed honestly; fix instrumentation before comparing nodes. The definition itself does not decide automation; it only separates waiting time from working time so the later 65% and median-cycle-time tests have a clean input.

![What a wait-state ratio actually measures — How to fix task bottlenecks](https://static.mm-ais.com/article-images-ai/how-to-fix-task-bottlenecks-65-wait-stat-ai-a5e2c782.jpg)

## The evidence: what sources support

Nulab’s June 2025 bottleneck guidance contains no published wait-state or automation threshold; its listed stopgaps are overtime, extra help, and pushed delivery dates, all described as costly and none as measured. That gap matters because it shows the guide’s cut-off is a policy ceiling rather than a benchmark reproduced from a source.

Nulab’s two examples are capacity stories, not threshold proofs: a cabinet production line where the cutting station processes 50 panels per day while assembly can handle 70, and a marketing agency where one creative director becomes the review constraint as writer submissions pile up. They demonstrate how a bottleneck forms and delays work, but they do not state when automation should replace deferral.

LearnLeanSigma’s September 16, 2026 guidance identifies bottlenecks through effective capacity, WIP, delay, and throughput evidence, then tells you to confirm the active constraint and verify system improvement. The sequence is diagnostic first and verification after the change, which is a process control habit rather than a single automation trigger.

Across Nulab and LearnLeanSigma, no universal threshold appears, and neither source converts a ratio into an automation decision. The cabinet and agency cases remain useful as illustrations of constraint and delay, not as evidence for a fixed cut-off. That is the sourced convergence this section owns: measurement and verification are supported; a universal automation threshold is not.

For a practical check, require any proposed automation trigger to name the source that publishes it and to show verification against the active constraint after implementation. If neither exists, treat the trigger as internal policy and keep the measurement, review, and deferral logic explicit.

A final boundary: the sources support measuring flow and verifying change, while the automation-versus-deferral rule remains a team-level policy choice. Keep that distinction visible in documentation so a measured bottleneck is not mistaken for a sourced mandate.

## Automate vs defer: the comparison

Use this table as a decision gate, not a to-do list: automation wins only when the node is both wait-heavy and slower than the team median for that task type. If either test fails, the cheaper lever is usually deferral, added capacity, or acceptance.

| Option | Trigger condition | Why it fits |
| --- | --- | --- |
| Automate the handoff (winner) | Wait-state ratio > 65% and cycle time > team median for the task type | Work is both waiting and slower than the team norm; removing the queue attacks the actual constraint. |
| Defer and re-measure one sprint | Ratio > 65% but cycle time ≤ team median | The queue may be a burst rather than a structural bottleneck; automation would encode temporary noise. |
| Add capacity | Ratio < 65% but cycle time > team median | Work is slow rather than waiting; more hands or skill fixes execution speed. |
| Accept | Ratio ≤ 65% and cycle time ≤ team median | No evidence of a constraint worth changing; leave the process alone. |

The reason both bars matter is that each metric isolates a different failure. A ratio above 65% says items spend most of their elapsed life not being worked; a cycle time above the team median says this node is slower than comparable work. Automation removes waiting, so it helps only when waiting is the binding constraint. If the ratio is high but cycle time is at or below median, the queue may clear without changing the process. If cycle time is high but the ratio is below 65%, the work itself is slow, and added capacity or skill is the better fix.

Nulab's agency example—one creative director reviewing everything—shows a wait-heavy node, but automating review routing only clears it if review is both the dominant wait and the slower-than-median step. If writers are the slow step, automation merely delivers work faster into an unchanged review bottleneck.

Treat the 65% level as a policy ceiling you set, not a published benchmark. After applying any option, re-run the same ledger in the next measurement window; a changed ratio or cycle time can move the node into a different cell, and the decision should move with it.

## Numbers and costs that matter

Measure each queue with two full sprints of state-transition timestamps—four to six weeks—before calling a bottleneck structural. A one-sprint window can catch a single illness, vacation, or handoff delay and mislabel a temporary hiccup as a permanent constraint; Nulab's short-term hiccup case is the warning, so the timestamp window must outlast one person's absence.

Treat the 65% ceiling as declared policy, not a published benchmark: write it into your operations document, state the measurement method beside it, and review it quarterly. It works like a missed-dependency cap—an internal control limit you set and revisit, not a result proven by an external study. If your team changes the definition of "waiting," version the document and date the change so old and new ratios are not compared silently.

Re-run the two-sprint ledger after any change to process, staffing, or tooling, and again at the quarterly policy review. If the queue's data is incomplete, keep the method and drop the number: record the missing timestamps, note the gap, and defer the automation decision until the next full window. A partial ledger is useful for diagnosis but not for a policy trigger.

For cost, use a method rather than a sourced figure: per deferred structural queue, cost is approximately (items waiting × average wait days × value at risk per item-day) plus (overtime hours × loaded labor rate). Pull both rates from your own payroll and revenue records; Nulab lists overtime, extra help, and pushed delivery dates as costly stopgaps, but gives no measured cost, so do not import an external rate. If value at risk is hard to estimate, use the cost of the overtime you would otherwise approve as the lower bound.

Keep the cost estimate separate from the trigger. The automation decision still requires the wait-state ratio and the node's median cycle time against your team median; the cost model only shows what deferral is likely to cost while you collect or re-check that evidence. Review the estimate when the queue changes, not when the invoice arrives.

## What the evidence does not establish

The 65%/median rule is a policy ceiling, not a published benchmark, and this section tabulates where that ceiling breaks versus where it still wins. Treat the table as a boundary check on the wait-state ledger: a high wait ratio plus an above-median cycle time is necessary for automation, but it is not sufficient when the blocker is external, personal, or statistically noisy.

The rule breaks in three cases. Regulatory or legal review queues are blocked by an external state; automation cannot shrink the review itself, so a high wait ratio there signals dependency, not automatable work. Single-approver nodes where the constraint is the person call for a capacity fix, not automation, because adding throughput to a queue that one reviewer must still clear does not remove the constraint. Teams under five people have noisy medians, so a node can look above median in one sprint and below it in the next; defer until the median stabilizes.

| Breaks the rule | Still wins |
| --- | --- |
| Regulatory or legal review queues with external blocked states | Repeated handoffs between named systems, such as CI sign-off or dependency updates |
| Single-approver nodes where the constraint is the person | Approval queues with stable volume across two or more sprints |
| Teams under five people with noisy medians | Handoffs that can be externalized as a graph rather than cleared by a person |

The rule still wins where the wait is structural rather than personal or external. Repeated handoffs between named systems, including CI sign-off and dependency updates, fit the graph-externalization pattern from this site's freeze-guide structure: the wait lives in the handoff, and automation can make that handoff explicit and repeatable. Approval queues with stable volume across two or more sprints also qualify, because stable volume gives the median a chance to mean something and gives automation a predictable load.

Use the table as a second gate after the ledger. If the blocker is outside the team or bound to one person, defer and fix capacity, ownership, or review routing. If the wait is a repeatable system handoff with stable volume, the 65%/median ceiling still points toward automation. In both cases, record why the rule was overridden so the next sprint's median is not polluted by an exception.

## The review queue

For a 'Design review' queue, run the full wait-state ledger over one sprint window. Pull every task that passed through and sum their total cycle time and their wait time (queued + blocked). Divide wait time by total cycle time to get the ratio. At the same time, pull the median cycle time for review-type tasks and compare it to your team median for that task type. Only if the ratio exceeds 65% and the review-type median sits above the team median are both bars cleared under the policy ceiling, pointing to automation for that node. Use your own observed figures; do not import numbers from another team's ledger.

Do not wait until the closeout to verify drift. Do not wait until the closeout to verify drift. Treat a mid-sprint checkpoint as required: if your running ratio is already above 65% mid-sprint, log the queued-versus-blocked split instead of assuming it will drop. The goal is not to chase the percentage down, but to know whether it is holding above the ceiling while the node is still slow relative to your team.

Mid-sprint, dig into the blocked sub-state and record the blocked-versus-queued split for the queue, because automation can only act on the handoff you can actually route. If the blocked share is mostly external, the target for automation must be different from a case where the wait is internal; a routing reminder is the part that can be handed off without changing the approval itself.

With the full ledger closed, apply this worksheet for any single queue: (1) wait-time ÷ total cycle time over one sprint, (2) median cycle time for that task type vs your team median, (3) at least one mid-sprint checkpoint, (4) blocked vs queued split. Only if (1) exceeds 65% and (2) is above your team median do you move to automation; otherwise you defer. The ratio is not a target to reach, only a result that must clear both bars.

## Worked Example: Run the Numbers

This section works one concrete numeric example end to end. For this illustration, the scenario is a "spec check" queue for a 4-person squad. The observation was taken over one sprint. From the squad's wait-state ledger for this node, 10 items were tracked: total wait-time logged as 44 hours, total active work logged as 22 hours, making total cycle time 66 hours. For this illustration, the wait-state ratio is 44 ÷ 66, which computes to 66.7%.

For this illustration, the second condition is checked against the task type: the squad's median cycle time for spec check is 5.5 hours per item, while this node's median cycle time for spec check is 6.2 hours per item. That means this node's median cycle time beats the team median for its task type. With the ratio at 66.7% (which exceeds 65%) and the median cycle time above the team median, both parts of the required pairing are met for this example.

For this illustration, the winner for this example is to automate this spec check node. The break-even trigger for this example is strict: if at the next sprint check the wait-state ratio falls to 65% or below, or if this node's median cycle time falls to the team median or below, the action must shift to defer for this node. No other option is declared the winner here, as this pairing is the only one that satisfies both conditions under the rule used for this example.

## Decision rules for your next sprint

For your next sprint, treat the 65% figure strictly as a policy ceiling, not a published benchmark. With that in mind, apply this gate: if the wait-state ratio exceeds 65% AND the node median cycle time is above your team median for that task type, automate the handoff this sprint. If only one of those two bars clears, defer for one sprint and re-measure from the queue ledger. Because no universal threshold exists across the fetched sources, this gate must be paired with a quarterly re-calibration of the 65% policy ceiling against your own team medians, or it will drift from policy into dogma.

Not every wait is yours to solve with tooling. If the wait is mostly blocked-state (an external party), never automate. Following Investopedia's long-term strategy category for production bottlenecks, the correct move is to escalate capacity or contract terms instead. Attempting to script around an outside dependency will not remove the block, and it will only commit effort to a handoff that cannot proceed without that action.

On the flip side, if the node median is high but the ratio is low, the work itself is slow. Do not touch tooling in that case. Instead, add capacity or split the task type. This distinction is vital, as mistaking a throughput drag for a wait drag is the fastest way to apply the automation trigger to the wrong problem.

Before you act on any of these rules, run three checks for that node over one sprint: confirm the ratio against the ceiling, confirm both medians against your team baseline, and classify for blocked-state. Only after all three are known should the if/then decide automate or defer. That discipline is the entire decision path for this sprint, with no other trigger to reach for.

## Frequently Asked Questions

**Which board states count toward the wait-state ratio's numerator?**

Queued (waiting to start) and Blocked (waiting on an external party) count as Yes, while Active and Review count as No.

**What denominator is used for the wait-state ratio?**

The ratio divides aggregated queued plus blocked time by total cycle time, the elapsed time across all four states.

**How does a wait-state ratio differ from a utilization-based bottleneck definition?**

A utilization-based definition identifies the busiest or most constrained resource, while the wait-state ratio shows where the delay actually lives in time.

**What does Nulab define as a bottleneck?**

Nulab defines a bottleneck as "any situation where work is delayed."

**What capacity mismatch does the cabinet line example show?**

A cutting station processes 50 panels per day while assembly can handle 70, so unfinished panels pile up.

**How should wait timestamps be obtained for the ratio?**

Pull wait timestamps from your board tool's state transitions rather than estimating from memory.

## Quick answers

| What rule does this guide use to decide between automate or defer? | This guide uses a 65% wait-state ratio and 2026 median cycle time to decide between automate or defer. |
| --- | --- |
| What does a wait-state ratio actually measure? | A wait-state ratio is wait-time divided by total cycle time: it measures how much of an item's elapsed life is spent not being worked. |
| Which states are included in the numerator when computing the wait-state ratio? | Queued (waiting to start) and Blocked (waiting on an external party) are included, while Active and Review are not. |
| How does the wait-state ratio differ from a utilization-based bottleneck definition? | A utilization-based bottleneck definition identifies the busiest or most constrained resource, while the wait-state ratio shows where the delay actually lives in time. |
| Where should wait timestamps be pulled from to compute the wait-state ratio? | Wait timestamps should be pulled from your board tool's state transitions rather than estimating from memory. |

Also worth reading: **Automate work handoffs vs manual runbooks: verify before you commit**: [Automate work handoffs vs manual](https://dotinc.app/blog/automate-work-handoffs-vs-manual-runbooks-verify-before-you-commit.php) · **Orchestration vs Automation: Dependency Resolution and Validation**: [Orchestration vs Automation: Dependency Resolution](https://dotinc.app/blog/orchestration-vs-automation-dependency-resolution-and-validation.php) · **AI work orchestration as the bridge between strategy and execution**: [AI work orchestration as the](https://dotinc.app/blog/ai-work-orchestration-as-the-bridge-between-strategy-and-execution.php)

### Related reading

- [Jira to Linear at 40 Engineers: What Cycle Time Data Shows](https://dotinc.app/blog/jira-to-linear-at-40-engineers-what-cycle-time-data-shows.php)
- [How to shift work on the fly: Task graphs cut delays by 65% vs manual in 2026](https://dotinc.app/blog/how-to-shift-work-on-the-fly-task-graphs-cut-delays-by-65-vs-manual-in-2026.php)
- [Release freeze decisions in 2026: 3-level dependency graph freeze vs ship](https://dotinc.app/blog/release-freeze-decisions-in-2026-3-level-dependency-graph-freeze-vs-ship.php)
- [Linear dependency blockers: test the 30% claim with a 4-week protocol](https://dotinc.app/blog/linear-dependency-blockers-test-the-30-claim-with-a-4-week-protocol.php)
- [AI Task Graphs for Incident Response: A Verify-Before-Commit Guide (2026)](https://dotinc.app/blog/ai-task-graphs-for-incident-response-a-verify-before-commit-guide-2026.php)
- [Automate work handoffs vs manual runbooks: verify before you commit](https://dotinc.app/blog/automate-work-handoffs-vs-manual-runbooks-verify-before-you-commit.php)

### Latest

- [How to shift work on the fly: Task graphs cut delays by 65% vs manual in 2026](https://dotinc.app/blog/how-to-shift-work-on-the-fly-task-graphs-cut-delays-by-65-vs-manual-in-2026.php)
- [Release freeze decisions in 2026: 3-level dependency graph freeze vs ship](https://dotinc.app/blog/release-freeze-decisions-in-2026-3-level-dependency-graph-freeze-vs-ship.php)
- [Linear dependency blockers: test the 30% claim with a 4-week protocol](https://dotinc.app/blog/linear-dependency-blockers-test-the-30-claim-with-a-4-week-protocol.php)

Canonical: https://dotinc.app/blog/how-to-fix-task-bottlenecks-65-wait-state-ratio-plus-median-cycle-time.php
Markdown: https://dotinc.app/blog/how-to-fix-task-bottlenecks-65-wait-state-ratio-plus-median-cycle-time.php/index.md