KANBAN
Learn how Kanban helps software delivery teams visualize work, limit work in progress, manage flow, make policies explicit, and improve using evidence from the system.
KANBAN BASICS
A Kanban board visualizes where work is.
Kanban as a management method helps you decide how work should move through that system.
See the workflow and the work currently moving through it.
Control how much work is started so the system can focus on finishing.
Observe how work moves, where it waits, and where it becomes stuck.
Agree on the rules governing how work enters, moves through, and leaves the system.
Review the system regularly using the work and evidence in front of you.
Change the system together based on what you learn.
THE SYSTEM
A workflow shows where work waits, where work is active, and how it moves from commitment to delivery.
Diagram
Your Kanban system should represent the workflow you want to manage, not simply reproduce the statuses already configured in Jira.
LIMITING WIP
More work in progress does not mean more work gets done.
System A
System B
More WIP tends to create more waiting and longer feedback loops. WIP limits create a constraint that encourages teams to finish existing work before pulling more in. Reducing WIP alone does not guarantee improvement.
Little’s Law. Over a stable period, Little’s Law connects average cycle time with average work in progress and average throughput.
FLOW METRICS
A board shows the work. Flow metrics show how the system behaves.
How much work is currently inside the system?
Count the work that has entered the measured workflow but has not left it.
How long does work take inside the measured workflow?
Measure the time between the defined start and end points of your workflow.
How much work does the system complete?
Count the work completed over a defined period.
How long has unfinished work already been in progress?
Measure how long each current item has spent inside the workflow.
Supporting measures provide more detail about where time is spent.
CYCLE TIME
Your work does not all take the same amount of time. Averages hide that variation.
Each dot represents a completed work item from June 28 to September 28, 2026. Half finished within 17 days, 85% within 22 days, and 95% within 25 days. Most finished between 14 and 22 days. A few took 25 days, and one took 28.
Percentiles show how often work finished within a given time. An SLE can use that historical performance, such as 85% within 22 days, instead of assuming every item will take the average.
WORK ITEM AGE
Don’t wait until work is late to discover it is in trouble.
On September 28, 2026, 23 items were in progress with an average age of 19 days. Eighteen were waiting in Ready for SIT, aged from 8 to about 29 days. Most were between 19 and 26 days old, placing many near or beyond the 22-day 85th percentile. One item in Development at about 4 days and two in Code Review at about 6 days remained within the normal range.
The daily conversation changes from “What did you do yesterday?” to “Which work is most at risk of taking longer than usual, and what can we do to finish it?”
DAILY MANAGEMENT
Use the board to manage work, not report individual activity.
Look at the oldest work first.
Look for blocked items.
Look for queues forming between process steps.
Ask what can be finished before starting something new.
Pull new work only when capacity is available.
PROCESS IMPROVEMENT
Don’t improve every time a number moves
Cycle time, throughput, and WIP change over time. That does not automatically mean the process changed. First distinguish meaningful signals from normal variation.
Natural process limits calculated from your team’s history help detect meaningful signals. Once you have one, investigate what is driving it, intervene with a targeted change, and measure what happens afterward.
FLOW FORECASTING
Forecast from flow, not item estimates
Predictability does not require estimating every item. Historical throughput provides another way to reason about delivery dates and scope.
Monte Carlo simulation uses historical throughput to answer two questions: “How much can we finish by this date?” and “When are these items likely to be done?” Results are expressed with confidence levels, without story points or estimates.
Doodle transitioned from story point estimates to no estimates with Nave in less than six months. Read Doodle’s story
KANBAN AND SCRUM
They are not necessarily mutually exclusive. Scrum provides a framework with defined accountabilities, events, and iterations. Kanban focuses on managing and improving flow. A Scrum team can use Kanban practices and flow metrics.
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed-length Sprints of one month or less | Continuous flow with replenishment on demand |
| WIP | No prescribed WIP limits | Explicit WIP limits |
| Pull | Work is planned for each Sprint | Work is pulled when capacity is available |
| Roles | Product Owner, Scrum Master, and Developers | No prescribed roles |
| Flow measurement | Flow metrics are not prescribed | Flow metrics measure system behavior |
| Planning | Sprint Planning for each Sprint | Replenishment on demand |
You don’t have to reorganize your entire team to start managing flow.
GETTING STARTED
Begin with your current workflow, then improve it using evidence.
Find where work really waits, not just where Jira says it is.
Define the workflow boundaries that matter to the customer.
See everything currently inside those boundaries.
Start controlling how much work enters each part of the system.
Use historical cycle-time data to understand how long work usually takes.
Intervene before outliers become extreme.
Look for changes in WIP, cycle time, and throughput.
Measure whether the change actually helped.
Nubank’s Global Productivity Team used Nave across 200+ teams. Read Nubank’s story
DEEPER RESOURCES
Explore the metrics, charts, policies, and forecasting methods used to manage flow.
Understand the charts and metrics used to analyze flow.
ReadRead cycle-time variation and percentiles from completed work.
ReadTrack unfinished work against historical cycle-time percentiles.
ReadSee how work accumulates and moves through the workflow.
ReadTrack completed work and distinguish signals from normal variation.
ReadForecast delivery dates or scope using historical throughput.
ReadCompare active work time with total cycle time.
ReadLearn how WIP limits encourage teams to finish before starting.
ReadConnect the board you already use and see its WIP, cycle time, throughput and work item age.