Agile-and-Scrum **Kanban Boards, Cycle Time, and Lead Time (ScrumBan Insights) – Zero-Fluff Study Guide**

Kanban Boards, Cycle Time, and Lead Time (ScrumBan Insights) – Zero-Fluff Study Guide

1. What This Is & Why It Matters

You’re a Scrum Team struggling with unpredictable sprints. Some tickets take 2 days, others 2 weeks, and stakeholders keep asking, "When will this be done?" You’ve tried velocity, but it’s not giving you real-time predictability.

Kanban boards, cycle time, and lead time are your superpowers for visualizing work, measuring flow, and making data-driven commitments—without abandoning Scrum. This is ScrumBan: Scrum’s structure + Kanban’s flow metrics.

Why this matters in production:
- Stakeholders stop micromanaging because you can say, "Based on our 95th percentile cycle time, this will take 5 days ± 1 day." - Bottlenecks become obvious—no more "Why is QA always blocked?" when the board shows 20 tickets in "Ready for Test." - You stop overcommitting because you’re not guessing—you’re using real historical data.

Real-world scenario:
You inherit a team where sprints are always late, but no one knows why. You introduce a Kanban board to visualize flow, track cycle time, and use lead time to set realistic expectations. Within two sprints, you reduce missed commitments by 40% and cut average delivery time by 25%.

2. Core Concepts & Components

? Kanban Board (in Scrum)

• Definition: A visual workflow tool that tracks work items (e.g., user stories, bugs) through stages (columns) like "To Do," "In Progress," "Review," "Done."
• Production insight: If your "In Progress" column has 10+ tickets, you’re multitasking—which kills productivity. Limit work in progress (WIP) to 1-2 items per person.

? Work Item (Ticket)

• Definition: A single unit of work (e.g., a user story, bug fix, or task) that moves across the Kanban board.
• Production insight: If tickets are too big (e.g., "Build login system"), cycle time skyrockets. Break them into 1-3 day chunks.

? Work in Progress (WIP) Limits

• Definition: A cap on how many tickets can be in a column at once (e.g., "In Progress" WIP = 3).
• Production insight: Without WIP limits, context-switching destroys focus. Rule of thumb: WIP = # of team members × 1.5 (e.g., 5 devs → WIP = 7-8).

? Cycle Time

• Definition: The time a single work item takes from "started" to "done" (e.g., "Ticket #123 took 3 days from 'In Progress' to 'Done'").
• Production insight: Cycle time is your best predictor of future delivery. If your 95th percentile cycle time is 5 days, you can confidently say, "Most tickets will take ≤5 days."

? Lead Time

• Definition: The time from when a ticket is requested to when it’s delivered (e.g., "Stakeholder asked for feature X on Monday, delivered Friday → lead time = 5 days").
• Production insight: Lead time includes waiting time (e.g., "Ready for Dev"). If lead time is much longer than cycle time, your backlog is bloated.

? Throughput

• Definition: The number of tickets completed per time period (e.g., "We finish 8 tickets per sprint").
• Production insight: Throughput + cycle time = predictability. If throughput is 8 tickets/sprint and cycle time is 3 days, you can forecast when the backlog will be done.

? Cumulative Flow Diagram (CFD)

• Definition: A visual graph showing how many tickets are in each column over time.
• Production insight: If the "In Progress" band is growing, you have a bottleneck. If "Done" is flat, you’re not delivering.

? ScrumBan (Scrum + Kanban)

• Definition: A hybrid approach where you keep Scrum’s sprints, roles, and events but add Kanban’s flow metrics (cycle time, WIP limits, CFD).
• Production insight: ScrumBan is the best of both worlds—structure + flexibility. Use it when:
• Your sprints are unpredictable.
• You need real-time visibility into bottlenecks.
• Stakeholders demand data-driven forecasts.

3. Step-by-Step: Setting Up a Kanban Board & Tracking Metrics

Prerequisites

✅ A Scrum Team (or Kanban team) with 3-9 members.
✅ A digital tool (Jira, Trello, Azure DevOps, or even a physical board).
✅ Historical data (if available) for baseline metrics.

Step 1: Define Your Workflow (Columns)

Goal: Map your real process (not an ideal one).

? Pro Tip:
- Avoid "Waiting" columns—they hide bottlenecks. Instead, label tickets (e.g., "Blocked: Needs API Access").
- Limit "In Progress" to 1-2 tickets per person to reduce context-switching.

Step 2: Set Up WIP Limits

Goal: Prevent multitasking and force focus.

How to set WIP limits:
1. Start with a guess (e.g., "In Progress" WIP = 3).
2. Adjust based on data (if cycle time is too high, lower WIP).
3. Enforce them strictly—if a column hits WIP, stop starting new work and help unblock others.

Example (Jira):

Board Settings → Columns → Set WIP Limits
- "In Progress" = 3
- "Code Review" = 2
- "Testing" = 2

? Pro Tip:
- If WIP limits are ignored, the team will keep multitasking → longer cycle times.
- Use "swimlanes" for different work types (e.g., bugs vs. features).

Step 3: Track Cycle Time & Lead Time

Goal: Measure how long work actually takes (not estimates).

Cycle Time

• Starts when: Ticket moves to "In Progress".
• Ends when: Ticket moves to "Done".
• How to track:
• Jira: Use the Control Chart report.
• Trello: Use Butler automation to log timestamps.
• Manual: Record start/end dates in a spreadsheet.

Example (Jira Control Chart):

Reports → Control Chart → Filter by "Last 30 Days"

Output:
- Average cycle time: 4.2 days - 95th percentile: 7 days (use this for forecasts!)

Lead Time

• Starts when: Ticket is created (or moved to "To Do").
• Ends when: Ticket moves to "Done".
• How to track:
• Jira: Use Cycle Time report (set start column to "To Do").
• Manual: Subtract creation date from completion date.

? Pro Tip:
- If lead time >> cycle time, your backlog is too big → prioritize ruthlessly.
- Use percentiles (85th, 95th) for realistic forecasts (not averages).

Step 4: Visualize Flow with a Cumulative Flow Diagram (CFD)

Goal: Spot bottlenecks at a glance.

How to generate a CFD:
1. Jira: Reports → Cumulative Flow Diagram 2. Trello: Use Trello Power-Ups (e.g., "Burndown for Trello").
3. Manual: Plot daily ticket counts per column in Excel.

What to look for:
| CFD Pattern | Problem | Fix | |-------------|---------|-----| | "In Progress" band growing | Too much WIP | Lower WIP limits | | "Ready for Test" band growing | QA bottleneck | Add QA resources or automate tests | | "Done" band flat | Not delivering | Unblock testing/review | | All bands growing | Backlog bloat | Stop adding new work |

Example (Jira CFD):

Reports → Cumulative Flow Diagram → Last 30 Days

Output:
- "Ready for Test" band is wider than "Testing" → QA is a bottleneck.

Step 5: Forecast Delivery with Cycle Time

Goal: Answer "When will this be done?" with data.

How to forecast:
1. Calculate 95th percentile cycle time (e.g., 7 days).
2. Count remaining tickets (e.g., 10 tickets).
3. Multiply: 10 tickets × 7 days = 70 days.
4. Add buffer: 70 days × 1.2 (20% buffer) = 84 days.

Example (Excel):

=PERCENTILE.INC(cycle_times, 0.95)  // 95th percentile
=COUNTIF(status, "To Do") * 95th_percentile  // Forecast

? Pro Tip:
- Never use averages—they underestimate risk.
- Update forecasts weekly as cycle time changes.

4. ? Production-Ready Best Practices

? Workflow Optimization

• Limit WIP per person to 1-2 tickets to reduce context-switching.
• Avoid "Waiting" columns—they hide bottlenecks. Use labels instead (e.g., "Blocked: Needs API Access").
• Refine tickets before "Ready for Dev"—unclear tickets = longer cycle time.

? Metrics & Forecasting

• Track cycle time per work type (e.g., bugs vs. features).
• Use 85th/95th percentiles for realistic forecasts (not averages).
• Update WIP limits monthly—if cycle time is too high, lower WIP.

? Team Culture

• Daily standups should focus on flow (e.g., "What’s blocking us from finishing these 3 tickets?").
• Retrospectives should analyze CFD (e.g., "Why did 'Ready for Test' grow last sprint?").
• Celebrate reducing cycle time—it means faster delivery.

? Tooling

• Jira: Use Control Chart + CFD for metrics.
• Trello: Use Butler automation for cycle time tracking.
• Azure DevOps: Use Flow Analytics for lead/cycle time.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (PSM, CSM, PSK)

? Typical Question Patterns

1. "What’s the difference between cycle time and lead time?"
2. Cycle time: Time from start to finish (e.g., "In Progress" → "Done").
3. Lead time: Time from request to delivery (e.g., "To Do" → "Done").

4. ⚠️ Trap: Lead time includes waiting time (e.g., "Ready for Dev").

5. "How do WIP limits improve flow?"

6. Answer: They reduce multitasking, expose bottlenecks, and shorten cycle time.

7. ⚠️ Trap: WIP limits don’t mean "work faster"—they mean work smarter.

8. "What’s the best way to forecast delivery?"

9. Answer: 95th percentile cycle time × remaining tickets.

10. ⚠️ Trap: Never use averages—they underestimate risk.

11. "What does a growing 'In Progress' band in a CFD indicate?"

12. Answer: Too much WIP → lower WIP limits.
13. ⚠️ Trap: It’s not always a bottleneck—could be too many tickets started.

? Scenario-Based Questions

Q: "Your team’s cycle time is 5 days, but stakeholders want a feature in 3 days. What do you do?" - A: Break the ticket into smaller pieces (e.g., "MVP in 3 days, enhancements later").
- ⚠️ Trap: Don’t just "work faster"—reduce scope.

Q: "Your CFD shows 'Ready for Test' growing. What’s the fix?" - A: Add QA resources or automate testing.
- ⚠️ Trap: Don’t just "try harder"—fix the bottleneck.

7. ? Hands-On Challenge (with Solution)

Challenge:

Your team’s cycle time is unpredictable (some tickets take 1 day, others 2 weeks). Set up a Kanban board in Jira with: 1. WIP limits for "In Progress" and "Code Review".
2. Track cycle time for the last 30 days.
3. Identify the 95th percentile cycle time.

Solution:

1. Create a Kanban board in Jira:
2. Boards → Create Board → Kanban Board

3. Columns: "To Do," "Ready for Dev," "In Progress," "Code Review," "Ready for Test," "Testing," "Done"

4. Set WIP limits:

5. Board Settings → Columns → Set WIP Limits

   
   
   • "In Progress" = 3
   • "Code Review" = 2

6. Track cycle time:

7. Reports → Control Chart → Filter "Last 30 Days"
8. 95th percentile cycle time = 7 days (use this for forecasts).

Why it works:
- WIP limits force focus.
- Cycle time tracking gives data-driven forecasts.
- 95th percentile accounts for outliers.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Scrum Guide 2020 – Official Scrum rules.
2. Kanban Guide for Scrum Teams – Scrum.org’s ScrumBan guide.
3. Actionable Agile Metrics (Book) – Deep dive into flow metrics.
4. Jira Kanban Tutorial – Hands-on setup guide.

Final Thought

Kanban boards + cycle time = predictability. You’ll stop guessing, deliver faster, and keep stakeholders happy. Start small—track cycle time for 2 sprints, then adjust WIP limits. The data will tell you what to fix.

Now go unblock your team. ?