Standard : Lead Time to Commit (Backlog Entry to Start)

Description

Lead Time to Commit measures the duration between when a work item is added to the backlog and when work actually begins. It reflects how long valuable work waits before being picked up, highlighting inefficiencies in prioritisation, backlog management, and planning throughput.

This metric helps teams understand how responsive they are to changing priorities and how long work is delayed by upfront queuing and backlog inflation.

How to Use

What to Measure

  • Start Point: When a work item is added to the product or team backlog (typically when it's ready for prioritisation or refinement).
  • End Point: When the team begins actively working on the item (e.g. moved to “In Progress”).

Measure:

  • Average lead time to commit per item type
  • Distribution of backlog wait times
  • Trends by epic, product area or team

Formula

Lead Time to Commit = Start Date – Backlog Entry Date

Where:

  • Start Date = when work begins (e.g. “In Progress”)
  • Backlog Entry Date = when item enters the actionable backlog

Instrumentation Tips

  • Capture backlog entry dates via ticket creation or refinement tagging.
  • Use consistent status transitions to mark the start of active work.
  • Visualise lead time trends using histograms or cumulative flow diagrams.
  • Track across different work types (features, bugs, spikes) to spot backlog bloat.

Benchmarks

Benchmarks depend on product complexity and backlog health. General guidance:

Item Type Healthy Range
Bugs/Incidents < 1–2 days
Small Stories < 5–10 days
Features < 2–4 weeks
Spikes/Exploratory < 1–2 weeks

Look for consistency and trends rather than fixed targets. Long wait times may signal prioritisation debt or misalignment.

Why It Matters

  • Improves responsiveness
    Helps teams understand how quickly they can act on new opportunities or needs.

  • Highlights backlog inefficiency
    Long lead times to commit often indicate overloaded or mismanaged backlogs.

  • Supports prioritisation clarity
    Encourages trimming, sequencing and focusing backlogs to avoid stale or idle work.

  • Informs capacity planning
    Aids in deciding how much work to queue and when to prepare it for delivery.

Best Practices

  • Regularly review backlog age and prune or reframe stale items.
  • Use flow-based planning rather than date-based commitments.
  • Limit backlog size to match throughput and planning horizon.
  • Visualise queue age to support refinement and prioritisation.
  • Track this metric in tandem with delivery lead time for a full value stream view.

Common Pitfalls

  • Allowing tickets to linger indefinitely in the backlog without refinement or removal.
  • Treating large backlogs as a sign of preparedness rather than risk.
  • Using inconsistent entry points for when items are considered “ready”.
  • Failing to distinguish between strategic initiatives and low-value tasks.

Signals of Success

  • Decreasing average lead time to commit across all item types.
  • Backlogs reflect current business priorities and customer needs.
  • Teams pull work with confidence and clarity, not guesswork.
  • Prioritisation decisions are visible, deliberate and regularly reviewed.
  • [[Cycle Time per Work Item Type]]
  • [[Customer Value Lead Time]]
  • [[Work Item Age]]
  • [[WIP per Team or Stream]]
  • [[Flow Efficiency]]

Aligned Industry Research

  • Lean Product and Agile Practices
    Emphasise minimising delay between identification and action to maximise responsiveness.

  • Flow Framework (Mik Kersten)
    Highlights time from idea to work start as a critical signal of flow efficiency in product development.

  • Value Stream Mapping (Rother & Shook)
    Encourages visibility into pre-commit delays to eliminate non-value-adding backlog time.