Standard : Cycle Time

Description

Cycle Time measures the total elapsed time from when work begins (e.g. development starts) to when it is delivered to production or a customer-facing environment. It is a core indicator of flow efficiency and a key part of understanding the developer experience.

Shorter cycle times indicate that work is moving through the delivery pipeline efficiently, while longer cycle times can reveal bottlenecks, rework, or blockers in the system.

How to Use

What to Measure

  • Track the time between first commit (or ticket status change to "In Progress") and successful deployment to production.
  • Optionally break down by workflow stage (e.g. coding, review, testing, deploy) to identify hotspots.

Formula

Cycle Time = Delivery Timestamp – Start of Work Timestamp

Instrumentation Tips

  • Integrate workflow tools (e.g. Jira, Azure Boards) and VCS (e.g. GitHub/GitLab) to timestamp stages.
  • Visualise cumulative flow and average time per stage in dashboards.
  • Consider cycle time per ticket, story, or pull request.

Why It Matters

  • Flow efficiency: Shorter cycle time means faster value delivery.
  • Developer experience: Long delays cause frustration and context-switching.
  • Predictability: Stable cycle time enables better planning and forecasting.
  • Insight: Helps identify slowdowns across review, testing, or release.

Best Practices

  • Limit work in progress (WIP) to reduce multitasking and flow fragmentation.
  • Automate testing, builds, and deployments to shrink idle time.
  • Track and visualise cycle time over time per team/service.
  • Run regular value stream mapping workshops to expose systemic blockers.
  • Standardise ticket lifecycle stages to ensure data consistency.

Common Pitfalls

  • Measuring from ticket creation instead of real start of work.
  • Not differentiating between working time and waiting time.
  • Tracking only averages—outliers can hide significant delays.
  • Ignoring rework loops (e.g. failed tests, rejected PRs).

Signals of Success

  • Stable or improving cycle time across sprints and releases.
  • Visible reduction in idle or wait time between stages.
  • Engineers report less friction and better flow.
  • Delivery reviews include cycle time data to drive retros and improvements.
  • [[Lead Time for Change]]
  • [[Time to Value]]
  • [[Work in Progress (WIP)]]
  • [[Pull Request Cycle Time]]
  • [[CoE/Measures/Delivery Performance/Deployment Frequency]]