## 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 ```python 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.

Flow

Development Cycle Time

Want to contribute?