Standard : Cycle Time per Work Item Type

Description

Cycle Time per Work Item Type measures how long it takes, on average, for a specific type of work (e.g. feature, bug, tech debt, spike) to move from “in progress” to “done.” This metric highlights the team's ability to complete work efficiently and consistently across different categories of value.

By analysing cycle times across work item types, teams gain insight into flow variation, delays, and capacity constraints. It’s a foundational metric for improving predictability, forecasting, and delivery confidence.

How to Use

What to Measure

  • Start point: When work begins (e.g. item moves to “In Progress” or equivalent).
  • End point: When work is completed (e.g. item reaches “Done” or released to production).
  • Group cycle time data by item type (e.g. story, bug, chore, enhancement, spike).

Formula

Cycle Time = Date Completed – Date Work Started

You should calculate and analyse:

  • Average cycle time per item type
  • Distribution of cycle times (e.g. percentiles, outliers)
  • Trends over time (weekly or per sprint)

Instrumentation Tips

  • Use workflow tools (Jira, Azure DevOps, Trello, etc.) with timestamps on status transitions.
  • Tag or categorise work items consistently by type.
  • Visualise data using scatter plots, histograms or cumulative flow diagrams (CFDs).
  • Track both average and variability to surface inconsistencies.

Benchmarks

Benchmarks vary by team, domain and item type, but general guidance:

Work Item Type Healthy Range
User Stories 1–5 days
Bugs 1–3 days
Spikes 1–4 days
Technical Debt 2–6 days
Features/Epics Split into smaller items for accuracy

Track your team's baseline and aim to reduce variability and improve predictability, rather than comparing blindly to other teams.

Why It Matters

  • Improves predictability
    Teams with stable cycle times can forecast delivery more confidently.

  • Supports flow-based delivery
    Encourages focus on completing work rather than starting new work.

  • Exposes delays and inefficiencies
    Identifies bottlenecks, blockers or excessive handoffs.

  • Differentiates work types
    Helps teams spot if certain types of work (e.g. bugs or tech debt) are consistently slower.

Best Practices

  • Track cycle time continuously and review in retrospectives.
  • Categorise work clearly and maintain hygiene in ticket statuses.
  • Visualise work in progress using Kanban boards with explicit columns.
  • Address ageing items or those exceeding target thresholds.
  • Use flow metrics alongside throughput and WIP to understand system behaviour.

Common Pitfalls

  • Using inconsistent or unclear definitions of start and end states.
  • Measuring only average values without reviewing the spread (variance, outliers).
  • Ignoring the difference between work types and lumping all work together.
  • Focusing solely on speed, neglecting quality or value of outcomes.

Signals of Success

  • Stable cycle times across sprints or weeks for common work types.
  • Decreasing trend of outlier items taking excessively long.
  • Improvements in predictability and estimation accuracy.
  • Proactive response to increasing cycle times or delayed work.
  • [[Throughput Rate (Items Completed per Sprint or Week)]]
  • [[Work Item Age]]
  • [[Throughput Rate (Items Completed per Sprint or Week)]]
  • [[Blocked Time per Work Item]]

Aligned Industry Research

  • Accelerate (Forsgren et al.)
    Emphasises reducing lead time and variability to drive delivery performance.

  • Kanban Method (David J. Anderson)
    Advocates measuring and managing cycle time to improve flow and forecasting.

  • Flow Metrics for Scrum Teams (ActionableAgile)
    Recommends tracking cycle time by item type to inform process improvement.