Waiting Time measures the accumulated time items spend in non-active workflow states — blocked, awaiting review, awaiting QA, awaiting deploy. It's the most direct way to surface workflow friction.
What it measures
Total time items sit in passive states between active steps, summed across the period.
How Leanmote calculates it
For each item, sum the duration spent in non-active states (e.g., blocked, review, qa_pending, awaiting_deploy). Active development time is excluded — that's covered by Cycle Time.
The active vs. waiting state mapping comes from your workflow configuration.
Reported as average per item and as a percentage of total cycle time.
How to interpret it
Waiting Time as a percentage of Cycle Time tells you how much of an item's life is spent doing nothing. 60–80% is common; over 90% means the system is mostly queueing.
If Waiting Time is rising while Cycle Time is rising, the bottleneck is in a passive state, not in coding.
Localize by stage. The state with the longest waiting share is your highest-leverage improvement target.
What to do about it
If review is the longest wait: shorten review pickup time, set SLAs, distribute reviewer load.
If QA is the longest wait: invest in test automation and pre-merge quality gates.
If deploy is the longest wait: deploy more often or remove manual gates.
Cap WIP — fewer items in flight means less waiting per item.
Related metrics
Cycle Time
Work in Progress (WIP)
Review latency
Bottleneck Insights dashboard