• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Queue Time Between Workflow Stages

Description

Queue Time Between Workflow Stages measures how long work items wait between stages of the delivery process before active work resumes. These wait states—such as between development and testing, or testing and deployment—often represent hidden delays and system inefficiencies.

By surfacing queue time, teams can identify where handoffs, approvals, or prioritisation gaps are slowing down delivery. This enables more focused process improvement and fosters continuous flow.

How to Use

What to Measure

  • Measure the time a work item spends not being actively worked on between two workflow stages.
  • Common queue states include:
    • Ready for Development
    • Awaiting Code Review
    • Waiting for Testing
    • Ready for Release

Track queue times per stage transition and item type.

Formula

Queue Time = Time Entered Queue – Time Work Began in Next Stage

You may also calculate:

  • Total Queue Time per item
  • % of Total Cycle Time spent in queues

Instrumentation Tips

  • Define queue states explicitly in your workflow (e.g. columns labelled “Ready for…”).
  • Use timestamps in your tracking tool to identify transitions between workflow stages.
  • Visualise queue times using stacked cycle time charts or state-based histograms.
  • Review item history logs to identify long or repeated wait periods.

Benchmarks

Benchmarks depend on the complexity and maturity of your delivery process. General guidance:

Queue State Healthy Max Queue Time
Ready for Dev < 1 day
Awaiting Review/Test < 1–2 days
Ready for Release < 1–3 days

More important than absolute values is tracking consistency and improvement over time.

Why It Matters

  • Surfaces invisible bottlenecks
    Long queues delay feedback and hide inefficiencies in handoffs.

  • Improves system flow
    Reducing queue time increases throughput and predictability.

  • Supports lean optimisation
    Encourages teams to pull work when ready instead of pushing work into queues.

  • Enables better resource allocation
    Highlights where teams may be overburdened or under-resourced.

Best Practices

  • Explicitly model queues in your boards and workflows.
  • Set service level expectations (SLEs) for acceptable wait times per queue.
  • Use WIP limits on downstream stages to prevent work from piling up.
  • Address policy, tooling or cultural blockers that extend queue times.
  • Continuously review state transitions in retros and flow reviews.

Common Pitfalls

  • Treating queues as passive holding areas without responsibility.
  • Failing to distinguish between queue states and active work.
  • Letting queues build up due to unbalanced capacity or unclear ownership.
  • Normalising long queue times rather than addressing systemic causes.

Signals of Success

  • Decrease in average queue time across key transitions.
  • Balanced flow across stages with minimal handoff delays.
  • Teams pull work when ready, not when pushed from upstream.
  • Process improvements are targeted at stages with consistently high queue time.

Related Measures

  • [[Flow Efficiency]]
  • [[Blocked Time per Work Item]]
  • [[Cycle Time per Work Item Type]]
  • [[Work Item Age]]
  • [[WIP per Team or Stream]]

Aligned Industry Research

  • Lean Thinking (Womack & Jones)
    Highlights waiting as one of the seven forms of waste that degrade flow.

  • Value Stream Mapping (Rother & Shook)
    Emphasises time spent waiting between steps as a key target for optimisation.

  • Kanban Method (David J. Anderson)
    Advocates making queues visible and limiting upstream flow to reduce delivery delays.

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering