Blocked time percentage

Blocked time percentage is the share of total work time during which tasks are stalled and cannot progress because they are waiting on a dependency, a decision, or another person. It separates time spent actively working from time spent waiting in a queue. A task that takes ten days to complete but only involved two days of active work spent eight days blocked, and that is the gap this metric makes visible.

The metric matters because waiting time is usually invisible. Teams measure how long work takes from start to finish, but that total hides whether the delay came from the work being hard or from the work sitting idle. Blocked time percentage isolates the idle portion, which is almost always the cheapest delay to remove because it requires unsticking a queue rather than doing more work.

It is closely related to cycle time, but it answers a different question. Cycle time tells you how long work takes overall, while blocked time percentage tells you how much of that duration was avoidable waiting rather than genuine effort.

A worked example shows why the distinction is useful. Suppose a team finishes work in an average cycle time of twelve days, and the items spent a combined total equivalent to four of those days in a blocked state. Blocked time percentage is four divided by twelve, or 33 per cent. One third of the elapsed time was waiting, which points the team at queue and handoff problems rather than at working faster.

Blocked time percentage divides time spent in a blocked state by total cycle time, then multiplies by 100. The accuracy of the figure depends entirely on how reliably blocked time is captured, so the practical work is in recording when items enter and leave the blocked state, not in the arithmetic.

1. 1

   Define what counts as blocked

   Agree the states that mean an item is waiting on something external, such as awaiting review, awaiting approval, or waiting on another team. A shared definition keeps the measure consistent across people.

2. 2

   Capture time entering and leaving blocked

   Record the timestamp whenever an item moves into a blocked state and when it leaves. Most work trackers log these transitions automatically once the blocked states are defined.

3. 3

   Sum blocked time across items

   Add up the total time spent blocked across all the items in the period you are measuring, so the figure reflects the whole flow rather than one task.

4. 4

   Divide by total cycle time

   Divide total blocked time by total cycle time for the same items and multiply by 100 to express the result as a percentage of elapsed work time.

A metric tree breaks the overall figure into the specific stages where work waits. A single blocked time percentage tells you waiting is a problem, but not where. Decomposing it by the type of block, whether the wait is for a review, an approval, a dependency, or an external party, points each part of the delay at the team or step that owns it.

Blocked time percentage varies by the kind of work and how many handoffs it involves, so these ranges are reference points rather than targets. Work with few dependencies should sit low, while work that crosses many teams or external parties naturally carries more waiting. The bands below describe where flow is healthy and where it signals a queue problem.

Reducing blocked time is about shortening queues and removing the handoffs where work waits, not about pushing people to work faster. The actions below target the most common sources of waiting: slow reviews, approval bottlenecks, and dependencies that are not visible until they bite.

1. 1

   Counting parked work as blocked

   Items that are intentionally on hold or out of scope are not blocked, they are paused. Including them inflates the figure and hides the real waiting that improvement effort should target.

2. 2

   Relying on manual blocked flags

   If people have to remember to mark and unmark items as blocked, the data is patchy. Derive blocked states from workflow status transitions wherever possible so the measure is consistent.

3. 3

   Reading the headline without the breakdown

   A single blocked time percentage tells you there is a queue problem but not where it sits. Without splitting it by review, approval, and dependency waits, teams optimise the wrong stage.