Development Cycle Time

Overview

Development Cycle Time measures the elapsed time from when work begins (status changes to "In Progress") to when it's completed (status changes to "Done"). It's a critical flow metric that reveals how quickly your team delivers value once work starts.

Why It Matters

• Predictability: Understand how long work actually takes
• Bottleneck detection: Find where work gets stuck
• Process improvement: Measure impact of changes
• Capacity planning: Make realistic commitments
• Customer responsiveness: Deliver faster feedback
• Team health: Long cycle times indicate problems

Cycle Time vs. Lead Time

Timeline:
─────────────────────────────────────────────────────────
Backlog → In Progress → Code Review → Testing → Done
   │←──── Lead Time (full journey) ──────────────→│
         │←──── Cycle Time (active work) ────→│

Lead Time: Total time from request to delivery
Cycle Time: Time actively working on the task

Key Difference:
- Lead Time includes waiting in backlog
- Cycle Time only includes active development

How to Measure

Basic Calculation

Cycle Time = Completion Time - Start Time

Example:
- Started: Monday 9:00 AM
- Completed: Tuesday 3:00 PM
- Cycle Time: 30 hours (1.25 days)

What Counts as "Started"?

Choose based on your workflow:

• In Progress: Developer begins work (most common)
• First Commit: First code written
• Branch Created: Work branch created
• Assigned: Ticket assigned to developer

What Counts as "Done"?

• Merged to Main: Code merged (recommended)
• Deployed to Production: Live for users
• Passed QA: All testing complete
• Story Accepted: Product owner approves

Stages to Track

Typical Workflow:
1. In Progress → Development
2. Code Review → Waiting for reviewers
3. Review Changes → Addressing feedback
4. Testing → QA validation
5. Done → Merged/Deployed

Track time in each stage to find bottlenecks

Recommended Visualizations

1. Histogram (Distribution)

Best for: Understanding typical cycle time

X-axis: Cycle time buckets (0-1d, 1-2d, 2-3d, 3-5d, 5-10d, 10d+)
Y-axis: Number of tasks
Insight: Shows your typical range and outliers

2. Percentile Chart (P50, P75, P95)

Best for: Tracking consistency over time

Y-axis: Cycle time (days)
X-axis: Time (weeks)
Lines: P50 (median), P75, P95
Target: Decreasing or stable trend

3. Control Chart (Statistical Process Control)

Best for: Identifying special causes of variation

Y-axis: Cycle time (days)
X-axis: Individual tasks (chronological)
Lines: Mean, Upper Control Limit, Lower Control Limit
Dots: Individual task cycle times
Insight: Points outside limits indicate process problems

4. Scatter Plot (Size vs. Time)

Best for: Understanding task sizing impact

X-axis: Story points or estimated size
Y-axis: Actual cycle time
Dots: Individual tasks
Trend line: Correlation between size and time
Insight: Helps calibrate estimates

5. Stacked Bar Chart (Time by Stage)

Best for: Identifying bottlenecks

Y-axis: Cycle time (hours/days)
X-axis: Time periods or task types
Stacked segments: Time in each workflow stage
Insight: Which stage takes longest?

Target Ranges

By Task Size

| Size | Target Cycle Time | Max Acceptable | |------|------------------|---------------| | XS (1 point) | < 4 hours | < 1 day | | S (2-3 points) | < 1 day | < 2 days | | M (5 points) | < 3 days | < 5 days | | L (8 points) | < 5 days | < 10 days | | XL (13+ points) | Break it down! | Should not exist |

By Team Performance Level

| Level | Median Cycle Time | 95th Percentile | |-------|------------------|----------------| | Elite | < 1 day | < 3 days | | High | 1-3 days | < 7 days | | Medium | 3-7 days | < 14 days | | Low | > 7 days | > 14 days |

By Work Type

Features: 2-5 days Bugs: < 1 day (prioritize fast fixes) Tech Debt: 3-7 days (often larger refactors) Hotfixes: < 4 hours (urgent)

How to Improve Cycle Time

1. Reduce Batch Size

Problem: Large tasks take forever Solution: Break work into smaller pieces

Before:
- 1 large feature: 13 points, 12 days

After:
- Phase 1: 3 points, 2 days
- Phase 2: 3 points, 2 days
- Phase 3: 5 points, 3 days
- Phase 4: 2 points, 1 day

Result: Incremental value, faster feedback

2. Limit Work in Progress (WIP)

Problem: Context switching slows everything down Solution: Finish before starting new work

Team of 5:
- WIP Limit: 5 (one per person)
- Rule: Only start new work when something completes
- Result: Finish fast, start less often

3. Optimize Code Review

Problem: Reviews take 2-3 days Solutions:

• Set SLA: Review within 4 hours
• Smaller PRs: < 400 lines of code
• Async-first: Detailed descriptions
• Auto-assign reviewers (CODEOWNERS)
• Review during specific times (e.g., after standup)

4. Reduce Dependencies

Problem: Waiting for other teams/services Solutions:

• Identify common dependencies
• Create shared libraries
• Mock dependencies for testing
• Parallel development tracks

5. Automate Testing

Problem: Manual QA adds days Solutions:

• Comprehensive automated tests
• CI/CD pipeline runs all tests
• Parallel test execution
• Smoke tests for quick validation

6. Remove Handoffs

Problem: Each handoff adds wait time Solutions:

• Cross-functional teams (dev + QA + design)
• Developers own quality (not separate QA)
• Pair programming (built-in review)
• DevOps culture (deploy your own code)

7. Clear Priorities

Problem: Unclear what to work on leads to thrashing Solutions:

• Single prioritized backlog
• Weekly planning with clear priorities
• Escalation process for urgent work
• Protect team from ad-hoc requests

Common Pitfalls

❌ Comparing Teams

Problem: Team A has 2-day cycle time, Team B has 5-day Solution: Don't compare—different domains, complexity, maturity

❌ Gaming the Metric

Problem: Moving tickets to "In Progress" late to look faster Solution: Track from actual start (first commit, branch creation)

❌ Ignoring Outliers

Problem: Only looking at average, missing long-tail tasks Solution: Track P50, P75, P95 to understand full distribution

❌ Not Segmenting by Type

Problem: Mixing bugs, features, and tech debt Solution: Track cycle time separately by work type

❌ Pressure to Go Faster

Problem: Using as performance metric creates stress Solution: Use for process improvement, not individual evaluation

Implementation Guide

Week 1: Define Workflow States

Your Workflow:
1. Todo → Not started
2. In Progress → Developer working
3. Code Review → Awaiting review
4. Review Changes → Addressing feedback
5. Testing → QA validation
6. Done → Merged/Deployed

Define clearly:
- What triggers transition to "In Progress"?
- What criteria for "Done"?
- Who moves tickets between states?

Week 2: Configure Tooling

Jira Configuration:
1. Create custom field: "Started Date"
2. Add automation: Set "Started Date" when status → "In Progress"
3. Create report: Time between "Started Date" and "Done"

OR use Jira's built-in cycle time report:
Boards → Reports → Cycle Time

Week 3: Establish Baseline

• Measure cycle time for 2-3 sprints
• Calculate P50, P75, P95
• Identify patterns (day of week, task type, etc.)
• Document bottlenecks

Week 4: Set Targets & Improve

• Set realistic improvement goals
• Focus on biggest bottleneck
• Implement one improvement
• Measure impact

Dashboard Example

Team View

┌────────────────────────────────────────────────┐
│ Development Cycle Time                         │
│                                                │
│ Median (P50): 2.3 days                        │
│ ███████████░░░░░░░░░░░░░░ Good                 │
│                                                │
│ Distribution (Last 30 Days):                   │
│ • P50 (Median):    2.3 days                   │
│ • P75:             4.1 days                   │
│ • P95:             8.7 days                   │
│                                                │
│ Trend: ↓ 15% vs. last month                   │
│                                                │
│ By Work Type:                                  │
│ • Bugs:      0.8 days  ✓ Fast                 │
│ • Features:  3.2 days  Good                   │
│ • Tech Debt: 5.1 days  Acceptable             │
└────────────────────────────────────────────────┘

Bottleneck Analysis

Time Breakdown (Average)
──────────────────────────────────────────────
Stage              Time      % of Cycle  Status
──────────────────────────────────────────────
Development        1.2 days  35%         ✓
Code Review        1.5 days  44%         ⚠️ BOTTLENECK
Review Changes     0.3 days  9%          ✓
Testing            0.4 days  12%         ✓
──────────────────────────────────────────────
Total Cycle Time   3.4 days  100%

Action: Improve code review SLA from 24h → 4h
Estimated Impact: Reduce cycle time to 2.5 days (-26%)

Histogram View

Cycle Time Distribution (Last 60 Days)
────────────────────────────────────────
  25 │     ■■■■■■■
  20 │     ■■■■■■■
  15 │  ■■ ■■■■■■■
  10 │  ■■ ■■■■■■■  ■■
   5 │■■■■ ■■■■■■■  ■■  ■■
   0 ├──────────────────────────
     0-1  1-2 2-3 3-5 5-7  7-10 10+
          Cycle Time (Days)

Insights:
• Mode: 2-3 days (most common)
• Median: 2.8 days (typical)
• Long tail: 10+ days (5 tasks) ← Investigate

Related Metrics

• Lead Time for Changes: Commit to production (DORA metric)
• Sprint Velocity: Total work completed per sprint
• Code Review Time: Isolated review bottleneck
• Work in Progress (WIP): How much work is active
• Throughput: Number of tasks completed per week

Tools & Integrations

Native Platform Features

• Jira: Cycle time reports, control charts
• Linear: Cycle analytics built-in
• Azure DevOps: Cycle time widgets
• GitHub Projects: Insights (beta)

Third-Party Analytics

• ActionableAgile: Advanced flow metrics
• Plandek: Engineering intelligence
• Swarmia: Team analytics
• Haystack: Engineering metrics
• Pluralsight Flow: Development analytics

DIY Approach

import pandas as pd

# Load ticket data from Jira/Linear
tickets = pd.read_csv('tickets.csv')  # id, started_at, completed_at

# Calculate cycle time
tickets['cycle_time_hours'] = (
    tickets['completed_at'] - tickets['started_at']
).dt.total_seconds() / 3600

tickets['cycle_time_days'] = tickets['cycle_time_hours'] / 24

# Summary statistics
print(f"Median: {tickets['cycle_time_days'].median():.1f} days")
print(f"P75: {tickets['cycle_time_days'].quantile(0.75):.1f} days")
print(f"P95: {tickets['cycle_time_days'].quantile(0.95):.1f} days")

# By work type
print("\nBy Work Type:")
print(tickets.groupby('type')['cycle_time_days'].median())

Questions to Ask

For Planning

• What's our typical cycle time for small/medium/large tasks?
• How long should we estimate for this type of work?
• Can we deliver this feature in one sprint?

For Process Improvement

• Where do tasks spend the most time?
• Which stage is our biggest bottleneck?
• Are certain types of work consistently slow?
• What would reduce cycle time most effectively?

For Leadership

• Is our cycle time improving or deteriorating?
• Are we delivering value quickly enough?
• Do we need to invest in tooling or process changes?

Success Stories

SaaS Startup

• Before: 7-day median cycle time, unpredictable delivery
• After: 2-day median cycle time, consistent flow
• Changes:
  • Broke down large stories (nothing > 5 points)
  • WIP limit: 1 per engineer
  • 4-hour code review SLA
  • Automated testing (manual QA eliminated)
• Impact: 3.5x faster delivery, improved team morale

E-commerce Company

• Before: 12-day cycle time, features took months
• After: 3-day cycle time, rapid iteration
• Changes:
  • Eliminated separate QA handoff (devs own quality)
  • Feature flags (deploy incomplete features)
  • Microservices reduced dependencies
  • Dedicated product engineer pairs
• Impact: 4x faster time-to-market, revenue growth accelerated

Advanced Topics

Little's Law

Average Cycle Time = WIP / Throughput

Where:
- WIP = Average work in progress
- Throughput = Tasks completed per day

Example:
- WIP: 10 tasks
- Throughput: 5 tasks/day
- Cycle Time: 10 / 5 = 2 days

Insight: Reduce WIP to reduce cycle time!

Cumulative Flow Diagram

Visualizes WIP over time:

    │  ┌─────── Done (cumulative)
    │  │ ┌───── Testing
    │  │ │ ┌─── Code Review
    │  │ │ │ ┌─ In Progress
    │  │ │ │ │
  N │  ╱ ╱ ╱ ╱
  u │ ╱ ╱ ╱ ╱
  m │╱ ╱ ╱ ╱
  b │ ╱ ╱ ╱
  e │╱ ╱ ╱
  r │ ╱ ╱
    └──────────→ Time

Width of band = WIP in that stage
Wider = more WIP = longer cycle time

Cycle Time Percentiles

Use percentiles for commitments:

Customer: "How long will this feature take?"

Bad Answer: "2 days" (P50, 50% chance of missing)
Good Answer: "80% confident in 4 days" (P80)
Better Answer: "95% confident in 6 days" (P95)

Use higher percentiles for commitments to customers.

Conclusion

Development Cycle Time measures how quickly your team delivers once work starts. Track the median and P95, segment by work type, and use control charts to identify bottlenecks. Improve cycle time by reducing batch sizes, limiting WIP, optimizing code review, and removing handoffs. Remember: cycle time is a flow metric, not a performance metric. Use it to improve processes, not judge individuals. Elite teams achieve < 1-day median cycle time through small batches, low WIP, fast code review, and high automation. Start measuring today, find your biggest bottleneck, and incrementally improve. Faster cycle time means faster feedback, faster learning, and faster value delivery to customers.