Fatskills
Practice. Master. Repeat.
Study Guide: TECH **Kanban Boards, Cycle Time, and Lead Time: A Zero-Fluff, Hands-On Guide**
Source: https://www.fatskills.com/agile/chapter/tech-kanban-boards-cycle-time-and-lead-time-a-zero-fluff-hands-on-guide

TECH **Kanban Boards, Cycle Time, and Lead Time: A Zero-Fluff, Hands-On Guide**

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~9 min read

Kanban Boards, Cycle Time, and Lead Time: A Zero-Fluff, Hands-On Guide

(For Agile Teams, Scrum Masters, and Certification Takers)


1. What This Is & Why It Matters

You’re a Scrum Master or Agile coach on a team that’s drowning in "urgent" requests. Your sprints are packed, but work keeps piling up—bugs, feature requests, and last-minute "ASAP" tasks. Your stakeholders complain about slow delivery, but your team feels like they’re running in circles. Sound familiar?

This is where Kanban boards, cycle time, and lead time come in. They’re not just "nice-to-have" metrics—they’re your early warning system for bottlenecks, inefficiencies, and process breakdowns. If you ignore them: - Your team will keep overcommitting, leading to burnout.
- Stakeholders will lose trust because they can’t predict when work will be done.
- You’ll waste time in retrospectives guessing at problems instead of fixing them with data.

Real-world scenario:
You inherit a legacy Scrum team that’s been "doing Agile" for years but still misses deadlines. Your first move? Set up a Kanban board and track cycle/lead time. Within a week, you’ll spot: - A single "code review" column that’s holding up 80% of work.
- A "blocked" lane where tasks sit for days because no one owns them.
- A pattern where "small" tasks take 3x longer than estimated.

This guide will show you exactly how to set this up, measure it, and use it to improve flow—whether you’re running pure Kanban, ScrumBan, or just want to add Kanban principles to your Scrum team.


2. Core Concepts & Components


? Kanban Board

  • Definition: A visual workflow tool that tracks work items (cards) through stages (columns) from "To Do" to "Done."
  • Production insight: If your board has more than 7 columns, it’s probably too complex. Simplify to 3-5 key stages (e.g., "To Do," "In Progress," "Review," "Done").
  • Why it matters: Without a Kanban board, work is invisible. You can’t improve what you can’t see.

? Work Item (Card)

  • Definition: A single unit of work (e.g., a user story, bug, or task) represented as a card on the board.
  • Production insight: Cards should be small enough to complete in 1-2 days. If a card sits in "In Progress" for a week, it’s too big.
  • Why it matters: Oversized cards hide bottlenecks and make forecasting impossible.

? Work in Progress (WIP) Limits

  • Definition: A cap on the number of cards allowed in a column at once (e.g., "Max 3 cards in 'Code Review'").
  • Production insight: WIP limits force bottlenecks to surface. If "Testing" is always full, you know where to focus.
  • Why it matters: Without WIP limits, teams multitask, context-switch, and slow down.

? Cycle Time

  • Definition: The time it takes for a work item to move from start to finish (e.g., from "In Progress" to "Done").
  • Production insight: Cycle time is your predictability metric. If it’s consistently 5 days, you can promise stakeholders "next week."
  • Why it matters: If cycle time is unpredictable, you can’t plan releases or set realistic expectations.

? Lead Time

  • Definition: The time from when a work item is requested to when it’s delivered (includes waiting time).
  • Production insight: Lead time is customer-facing. If it’s 2 weeks but cycle time is 3 days, your backlog is the problem.
  • Why it matters: Long lead times = unhappy customers. Short lead times = competitive advantage.

? Throughput

  • Definition: The number of work items completed per time period (e.g., "10 stories per sprint").
  • Production insight: Throughput is output-focused. If it’s low, your team might be overloaded or blocked.
  • Why it matters: If throughput drops, you need to investigate why (e.g., too many meetings, unclear requirements).

? Cumulative Flow Diagram (CFD)

  • Definition: A chart showing the number of work items in each stage over time.
  • Production insight: A widening "In Progress" band = bottleneck forming. A flat "Done" line = no work getting finished.
  • Why it matters: CFDs predict future problems before they happen.

? ScrumBan

  • Definition: A hybrid of Scrum and Kanban, using Scrum’s roles/events but Kanban’s flow metrics.
  • Production insight: ScrumBan is great for teams transitioning from Scrum who want to reduce sprint overhead.
  • Why it matters: If your sprints feel rigid, ScrumBan lets you adapt mid-sprint without breaking Scrum rules.


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


Prerequisites

  • A tool (Jira, Trello, Azure DevOps, or even a physical board).
  • A team willing to experiment (even for 1 sprint).
  • Basic familiarity with Agile/Scrum (you know what a user story is).

Step 1: Define Your Workflow Columns

Goal: Map your team’s actual process (not an idealized one).

Example workflow for a software team:
| Column | Definition | WIP Limit | |-----------------|---------------------------------------------------------------------------|-----------| | To Do | Work accepted into the backlog but not started. | None | | In Progress | Actively being worked on (coding, designing, etc.). | 3 | | Code Review | Waiting for peer review. | 2 | | Testing | In QA or automated testing. | 2 | | Done | Completed and ready for release. | None |

? Pro tip: Start with fewer columns (3-5). Add more only if a bottleneck appears.

Step 2: Set WIP Limits

Goal: Prevent multitasking and expose bottlenecks.

How to set WIP limits:
1. Count how many cards are usually in each column.
2. Set the limit 10-20% lower than the current average.
- Example: If "In Progress" usually has 5 cards, set WIP = 4.
3. Adjust after 1-2 weeks based on flow.

? Pro tip: If a column hits its WIP limit, stop starting new work and help clear the bottleneck.

Step 3: Create Cards (Work Items)

Goal: Make work visible and measurable.

Card template (Jira/Trello example):


Title: [Short, actionable name]
Description: [What needs to be done? Why?]
Acceptance Criteria:
- [ ] Criterion 1
- [ ] Criterion 2
Size: [S/M/L or story points]
Assignee: [Who owns it?]
Labels: [bug, feature, tech-debt]

? Pro tip: If a card has no acceptance criteria, it’s not ready to start.

Step 4: Track Cycle Time & Lead Time

Goal: Measure how long work takes to complete.

How to track:
1. Cycle Time:
- Start timer when a card moves to "In Progress."
- Stop timer when it moves to "Done."
- Tools like Jira or Azure DevOps do this automatically.
2. Lead Time:
- Start timer when a card is created (or added to "To Do").
- Stop timer when it moves to "Done."

? Pro tip: Use a cycle time scatterplot to spot outliers (e.g., "Why did this one task take 10 days?").

Step 5: Generate a Cumulative Flow Diagram (CFD)

Goal: Visualize bottlenecks over time.

How to create a CFD (in Jira):
1. Go to Reports > Cumulative Flow Diagram.
2. Set the time range (e.g., last 30 days).
3. Look for:
- Widening bands = bottleneck (e.g., "Testing" is growing).
- Flat "Done" line = no work is finishing.

? Pro tip: If "In Progress" is growing faster than "Done," your team is starting too much work.

Step 6: Run a Flow Review (Kanban’s "Retrospective")

Goal: Improve the system, not blame people.

Agenda (15-30 min):
1. Review metrics:
- What’s our average cycle time? (e.g., 4.2 days)
- What’s our throughput? (e.g., 8 cards/week)
- Where are the bottlenecks? (CFD + WIP limits) 2. Ask:
- Why did [X] take so long?
- What’s blocking us from finishing faster?
- Should we adjust WIP limits? 3. Decide on 1-2 experiments (e.g., "Let’s reduce WIP in 'Code Review' from 3 to 2").

? Pro tip: Focus on system improvements, not individual performance.


4. ? Production-Ready Best Practices


? Process & Flow

  • Start with a physical board (even if remote) to build muscle memory.
  • Limit "In Progress" to 1-2 cards per person (prevents multitasking).
  • Use swimlanes for different work types (e.g., bugs vs. features).
  • Blocked cards? Add a "Blocked" column with a time limit (e.g., "If blocked > 1 day, escalate").

? Predictability & Planning

  • Use cycle time to forecast:
  • If average cycle time = 5 days, and you have 10 cards in "To Do," expect delivery in ~10 working days.
  • Avoid "gut feeling" estimates—let data drive commitments.
  • Track lead time separately to measure backlog health.

? Metrics & Reporting

  • Monitor these weekly:
  • Average cycle time (trend over time).
  • Throughput (cards/week).
  • % of work blocked (should be < 10%).
  • Share metrics with stakeholders (e.g., "Our cycle time is 4 days, so we’ll deliver X by Y").

? Continuous Improvement

  • Run flow reviews every 2 weeks (even if you’re doing Scrum).
  • Experiment with WIP limits—adjust them based on data.
  • Automate metrics (e.g., Jira dashboards, Power BI).


5. ⚠️ Common Mistakes & Traps

Mistake Symptom Fix/Prevention
No WIP limits Team is always "busy" but nothing gets done. Start with WIP = 1-2 per person. Adjust based on flow.
Too many columns Work gets "stuck" in obscure stages. Simplify to 3-5 key columns. Merge similar stages (e.g., "Dev" + "QA" = "Testing").
Ignoring blocked work Cards sit in "Blocked" for weeks. Add a "Blocked" column with a time limit (e.g., "If blocked > 1 day, escalate").
Measuring only velocity Team focuses on "points" instead of flow. Track cycle time and throughput instead. Velocity is a lagging indicator.
Not reviewing metrics Bottlenecks go unnoticed for months. Run a flow review every 2 weeks. Look at CFDs and cycle time trends.


6. ? Exam/Certification Focus


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" to "Done").
  3. Lead time: Time from request to delivery (includes waiting time).
  4. Trap: Lead time is always ≥ cycle time.

  5. "How do WIP limits improve flow?"

  6. They prevent multitasking and expose bottlenecks.
  7. Trap: WIP limits don’t mean "work faster"—they mean "finish what you start."

  8. "What does a widening band in a CFD indicate?"

  9. A bottleneck is forming (e.g., "Testing" is growing faster than "Done").
  10. Trap: A flat "Done" line means no work is finishing.

  11. "When should you use ScrumBan instead of Scrum?"

  12. When you need flexibility (e.g., interrupt-driven work like support tickets).
  13. When your sprints feel too rigid (e.g., mid-sprint changes are common).
  14. Trap: ScrumBan still needs WIP limits and flow metrics.

Key ⚠️ Trap Distinctions

Concept Scrum Kanban ScrumBan
Planning Fixed sprints (2-4 weeks). Continuous flow. Continuous flow + optional sprints.
Work Items Sprint backlog (committed). Pull-based (no commitment). Pull-based + optional sprint goals.
Metrics Velocity (story points). Cycle time, throughput. Cycle time, throughput, velocity.
Meetings Sprint planning, daily scrum, etc. Optional flow reviews. Flow reviews + optional Scrum events.


7. ? Hands-On Challenge (With Solution)


Challenge:

Your team’s Kanban board has 10 columns, and work is always "stuck" in "Code Review." Cycle time is unpredictable (3-15 days). Fix it in 3 steps.

Solution:

  1. Merge columns:
  2. Combine "Code Review" + "Testing" into "Review & Test" (WIP = 3).
  3. Set a WIP limit:
  4. "In Progress" = 2 per person.
  5. "Review & Test" = 3.
  6. Add a "Blocked" column:
  7. If a card is blocked > 1 day, move it here and escalate.

Why it works:
- Fewer columns = less handoff waste.
- WIP limits force the team to finish reviews before starting new work.
- "Blocked" column makes delays visible.


8. ? Rapid-Reference Crib Sheet


Kanban Board Setup

  • Columns: 3-5 max (e.g., "To Do," "In Progress," "Review," "Done").
  • WIP Limits: Start with 1-2 per person in "In Progress."
  • Card Size: Small enough to finish in 1-2 days.

Metrics

  • Cycle Time: "In Progress" → "Done" (predictability).
  • Lead Time: "Requested" → "Done" (customer-facing).
  • Throughput: Cards completed/week (output).
  • CFD: Widening bands = bottleneck.

Flow Review Agenda

  1. Review cycle time, throughput, and CFD.
  2. Identify bottlenecks (e.g., "Review" is always full).
  3. Adjust WIP limits or process (e.g., "Add a 'Pair Review' step").

ScrumBan Cheat Sheet

  • Planning: Optional sprints + continuous flow.
  • Work Items: Pull-based (no sprint commitment).
  • Metrics: Cycle time + throughput (not just velocity).
  • Meetings: Flow reviews (instead of retrospectives).


9. ? Where to Go Next

  1. Kanban Guide (Official) – The definitive resource.
  2. Actionable Agile Metrics (Book) – Deep dive into flow metrics.
  3. Jira Kanban Tutorial – Hands-on setup guide.
  4. ScrumBan Explained – Hybrid approach breakdown.

Final Thought

Kanban isn’t about "doing Agile right"—it’s about making work visible, measuring flow, and improving predictability. Start small: 1. Set up a board (even if it’s just sticky notes).
2. Track cycle time for 2 weeks.
3. Run a flow review and adjust.

You’ll instantly see where your process is broken—and how to fix it. ?



ADVERTISEMENT