Gear_Stream-EBook_Getting_Started_w_Kanban

The Lean-Agile eBook Practitioner Series 

GETTING STARTED 

WITH KANBAN 

A GUIDE FOR IMPLEMENTING 

LEAN & AGILE COLLABORATION 

ACROSS THE ENTIRE ENTERPRISE 

Brad Murphy, CEO 

brad.murphy@gearstream.com

© Copyright 2012 Gear Stream, Inc. 

CONTENTS 

1. AN INTRODUCTION TO KANBAN......................... 4 

2. VISUALIZE THE WORKFLOW..................................12 

3. LIMIT WIP...................................................................................20 

4. MEASURE AND MANAGE FLOW......................... 26 

5. MAKE PROCESS POLICIES EXPLICIT............. 36 

6. IMPROVE COLLABORATIVELY 

(USING MODELS)...............................................................44 

7. THE NEXT MOVE IS YOURS......................................48

FOREWORD 

Most CEOs dream of 

a future in which all 

employees, teams, and 

departments work in 

complete synchronicity. 

In this dream, a 

giant lever on human 

capital acts as a secret 

weapon in an age of 

global competition, 

hypercompetitive 

markets, and continuous 

commoditization of 

products and services. 

CEO surveys rank innovation and human capital among 

the primary corner office concerns, demonstrating that 

reality is far from this ideal scenario. 

How people organize and collaborate to get things 

done is the essence of business. When people are 

motivated and empowered to work together in highperforming 

teams, magic happens. 

The Agile movement has had much to say about 

enabling these kinds of hyperperforming teams so 

desperately needed today. It has also frequently 

promoted ideals that have proven elusive for most 

companies to implement, including team empowerment 

and self-direction. 

As an example, the fifth principle of the Agile Manifesto 

suggests that you should “build projects around 

motivated individuals” by “[giving] them the 

environment and support they need, and trust them to 

get the job done.” This implied a management style and 

skill set that is lacking in most IT divisions. 

So, how does Kanban succeed at scale where other 

methods have failed? 

Fundamental to Kanban is the principle of extreme 

visualization, within and across teams. When actualized, 

all teams are on the same page, understanding the 

relative volume, priority, and pacing of work items 

across their entire collaborative work community. 

The effective application of Kanban principles and 

practices results in teams that deliver 

disproportionately better results with respect to rates 

of innovation, output, productivity, and predictability. 

Kanban may well represent our best hope for bringing 

true innovation to business execution—and it may well 

be that elusive blueprint for true strategic advantage. 

By Brad Murphy 

Founder/CEO Gear Stream, Inc. 

© Copyright 2012 Gear Stream, Inc. 3

1. AN INTRODUCTION 

TO KANBAN

The word kanban has humble origins but has become synonymous with innovation— 

consistent innovation at companies like Microsoft and cutting-edge computer 

gaming companies. Kanban is a Japanese word that found its way into the Toyota 

Production System (TPS). Originally, kanban was an “open for business” sign—a 

visual indicator. On the Toyota production floor, kanban became a card signaling 

a need for parts replenishment. 

JAPAN 

If a chassis assembler ran low on a 

particular bolt, a color-coded card 

would be placed outside the 

workstation before running out of a 

particular item. Employees whose 

job was replenishment patrolled 

the production floor ceaselessly, 

refilling stock as needed. Thus, 

production continued 

uninterrupted. 

TPS formed the basis of Lean 

manufacturing, which bled over 

into Lean software development as 

a team concept. 

The purest view of a Lean control 

system is one that delivers the 

most value to the customer as 

quickly and efficiently as possible. 

There are several ways to optimize 

value delivery. In whichever 

industry they are used, Lean 

Principles use the following actions 

(and more) to ensure continuous 

and speedy workflow and produce 

customer value: 

• Limiting work in progress 

(WIP) so that the workload is 

manageable and feasible. Ideally, 

any one column (called a “state”) 

has one task at a time. 

• Implementing a pull system so 

that work begins only if work is 

required (for example, in reaction 

to a customer order). 

• Visualizing the workflow in 

steps that ultimately lead to 

the customer. This workflow is 

visualized on a Kanban board, 

usually a physical board with 

each work item represented on a 

single card (often, a sticky note). 

• Identifying bottlenecks and 

constraints in that workflow. This 

becomes easy using the visual 

Kanban board. For example: 

Are several work items backed 

up in one state, while the state 

after it is empty? The individuals 

responsible for work at the 

bottleneck need help. 

• Eliminating waste, such as 

unnecessary steps in the 

workflow, sources of defect, 

and the resultant rework. 

Inherent in the Kanban workflow 

is process improvement. The team 

reflects upon a body of work 

(perhaps all the work in the last 

week or two weeks) during a 

regularly scheduled retrospective, 

asks itself what went well and what 

went poorly, and then revises the 

upcoming workflow for 

improvement. Retrospectives allow 

the team to gather real-time 

metrics and chart how those 

metrics improve. 

The result is incremental, iterative 

improvement of both the products 

and the workflows themselves. 

Another result is flawless product, 

delivered timely, because team 

members apply their full attention 

and ingenuity to one piece of work 

at a time. 



?? 

? 

WHY YOU 

NEED 

KANBAN? 

A company may use 

Agile, but find that 

despite its promise 

compared with classic 

waterfall techniques, 

it, too, has some limits. 

Maybe the initial 

performance benefits 

have leveled off. Maybe 

teams still struggle with 

backlogs or risk-averse 

management has never 

gotten over the 

revolutionary tone 

of Agile. I was, after 

all, first described in 

a “Manifesto.” 

Kanban helps to overcome inertia and resistance to change. 

David J. Anderson described four reasons for implementing Kanban: 

1. To drive evolutionary, incremental 

change with minimal resistance 

2. To achieve sustainable pace by 

balancing throughput against 

demand 

3. To establish highly mature 

behavior aligned with senior 

management’s desire to have a 

highly predictable business 

4. To attain a better risk profile 

If your organization attempts to 

create revolutionary product but 

consistently fails to do so, can’t 

manage its workload, or 

management is primarily a 

bottleneck, then keep reading—this 

book (and Kanban) is for you! 

Why walk when we can run? 

New Kanban practitioners are eager 

to get going. They want revolution, 

not evolution. They are enthusiastic 

about improving their processes 

and delivering more value, which 

is good! 

But Gear Stream’s experience is 

that revolution flames out, quickly. 

Continuous incremental 

improvement and innovation is 

more achievable and sustainable 

in software development than 

attempting to scale a single, radical 

idea across the entire organization. 

This eBook provides companies 

with an understanding of Kanban 

such that they can both enable 

innovation and harness it in 

workflows. 

In time, as Kanban becomes a 

practice, innovation becomes 

embedded as well. 

RADICAL IDEAS 

ARE MARVELOUS— 

BUT INCREMENTAL 

IMPROVEMENTS ARE 

SOMETHING YOU CAN 

DO EVERY DAY AND 

WITH LESS RISK 

OF FAILURE!

THE 

PRINCIPLES 

OF KANBAN. 

Some magnificent minds 

have applied themselves 

to the problem of 

Kanban in software 

development—people like 

David J. Anderson, Don 

Reinertsen, and Mary 

and Tom Poppendieck. 

PRINCIPES OF KANBAN 

1. Visualize the workflow—know 

exactly where any work item is at 

any point in development 

2. Limit Work in Progress (WIP)— 

reduce cycle time (more on that 

later) and defects 

3. Measure and manage flow—use 

economic valuation to your 

benefit, not as a stumbling block 

4. Make process policies explicit— 

especially definitions of ready 

and done, acceptance criteria, 

and WIP limits 

5. Improve collaboratively—Kanban 

tools and time-tested Lean 

methods provide a means for 

learning collectively 

Anderson later suggested two more 

principles: 

6. Provide Leadership—grant 

permission for idea development 

and process innovation to 

anyone, anywhere 

7. Implement organizational 

feedback—quantitative measures 

of demand and capability 

and qualitative measure of 

collaboration and teamwork 

Each of the chapters in this book 

covers one of those five original 

principles. We believe the sixth 

and seventh are inherent in the 

Kanban process and will cover those 

throughout the other five chapters. 

These principles support the 

overarching goal of delivering 

customer value quickly and 

efficiently. 

The key enablers are 1) reduction 

in cycle time and 2) increased 

workflow effectiveness. Applied 

together these create prioritization 

at all levels of the organization 

through selection of items that are 

of the highest value to the customer. 

What are the 

prerequisites? 

None. 

You need not practice Lean or Agile 

to apply Kanban, but Kanban is an 

excellent way to get started in either. 

Kanban allows an organization to 

“start small” in one department or a 

function. Using Kanban to maximize 

its throughput and quality creates 

local improvement without global 

disruption. 

The only immediate change is that 

you make the current process 

visible, policies explicit, and 

structural impediments obvious. 

Change occurs as you begin a 

steady path of improvement. 

It is our experience that other 

departments and functions see the 

impact, and Kanban “goes viral.” 

Do not expect sweeping change! 

You are working with your existing 

processes, systems, and structures. 



SCRUM AND 

KANBAN – 

WHAT’S THE 

DIFFERENCE? 

Generally speaking, 

Kanban is more adaptive 

than Scrum. Its only real 

constraints are to 

1) Visualize your 

Workflow, 

2) Obey WIP limits, and 

3) Commit to continuous 

improvement. 

A team that is practicing Scrum typically adopts Kanban because it believes it can move 

faster by getting rid of some of the rigors of Scrum. 

Scrum and Kanban invite 

comparisons because they have 

much in common. For example: 

• Both are considered Lean and 

Agile 

• Both use a pull system 

• Both limit WIP 

• Both prescribe transparency to 

drive process improvement 

• Both use self-directed, crossfunctional 

teams 

Scrum 

Prescribes timeboxed iterations 

Team commits to a specific amount of work 

for an iteration 

Uses velocity as the default metric for planning 

and process improvement 

Prescribes a consistent size of work item, so 

each can be completed within one sprint 

Prescribes three roles: Product Owner, Scrum 

Master and Team 

• Both break a project into small 

deliverables (call them user 

stories, work items, minimal 

marketable features [MMFs], or 

what have you) 

But there are some differences, and 

author Henrik Kniberg (Lean From 

the Trenches) sums them up nicely. 

Kanban 

Time-boxed iterations optional; separate cadences for 

planning, release; process improvements allowable 

Commitment optional 

Uses lead time (or cycle time) 

Prescribes no particular size 

Prescribes no roles 

Consistency in the size of work 

items is one of the most significant 

differences. In Scrum it is called a 

Minimal Marketable Feature (MMF), 

which Denne and Cleland-Huang in 

Software by the Numbers describe 

as “A chunk of functionality that 

delivers a subset of the customer’s 

requirements.” The MMF is capable 

of returning value to the customer 

when released. Kanban allows for 

variation. A common feature in 

Kanban is to describe items by 

T-shirt sizes, like small, medium, 

large, and extra large. 

So which is the superior tool? 

Neither. In fact, Scrum teams may 

use Kanban (hence the term


KANBAN AND 

PROJECT 

MANAGEMENT 

– WHAT’S THE 

DIFFERENCE 

Do you want the whole 

list or just the top 10? 

CLASSIC PROJECT MANAGEMENT AND KANBAN 

ARE NOT THE SAME THING. KANBAN IS MORE 

FINITE IN SCOPE, FOCUSED PURELY UPON WIP 

AND THE VALUE STREAM. 

Project management is more prescriptive. It assigns 30+ roles, 

including Project Manager, Executive Sponsor, Project Sponsor/ 

Project Director, and Key Stakeholders. It also requires inputs from HR, 

accounting, risk management, and so forth. 

Project management prescribes more than 70 

artifacts, including the following: 

• a Project Charter 

• a Work Breakdown Structure (WBS) 

• a Risk Management Plan 

• a Stakeholder Analysis 

• an Issue Log 

• a Change Control Plan 

Kanban is not a substitute for classic project 

management, but at its best, it negates the need for 

much of that hands-on management and paperwork. 



SO IN 

KANBAN, 

NO ONE’S 

IN CHARGE? 

Not true. 

While Kanban does not 

prescribe formal roles, 

that hardly means 

anarchy in your 

engineering team. 

Kanban is meant to work with the existing hierarchy and framework. It does 

not prescribe roles because you already have them! QA continues to ensure 

quality, developers develop, and so forth. In fact, if you find yourself creating 

roles to make Kanban work, you are likely complicating your processes instead 

of simplifying them. 

Having said that, you should be able to name a Product Owner, just as you 

do in Lean, Agile, and classic Project Management. Whatever process you 

use, a Product Owner sets the Kanban priorities. He or she is the customer or 

represents the customer. 

Then who approves changes? 

That depends upon what you are 

changing. 

Note: 

A good Scrum team follows the 

same principle. 

The Product Owner is authorized 

to change work priorities; the team 

approves process changes. 

That’s right: the team itself knows 

how best to produce work. The 

team knows what enables smooth 

workflow and what enables shorter 

cycle times. 

This is not a no-rules environment 

of constant change. Changes are 

proposed, discussed, and agreed 

upon during retrospectives.


THAT’S 

PRETTY 

RADICAL! 

Remember, Kanban is a tool used to manage your existing 

process . . . and improve it. As part of improving that process, 

you will undoubtedly find yourself reducing documentation, 

making things more visible, and reducing WIP. 

Not really. 

Regarding documentation, if there 

is some prescribed process 

dictating requirements about the 

product (e.g., in military 

procurement or the FDA), then you 

are far less free to make process 

changes than a company that 

produces video games. And you 

probably can’t eliminate certain 

documentations or change 

how their data is collected 

and presented. 

If these are necessary, your Kanban 

board can incorporate the change 

control process of classic project 

management, and cycle times will 

have to include documentation. 

KANBAN DOES NOT REVOLUTIONIZE YOUR 

PROCESS ALL AT ONCE. IT IMPROVES THE 

ONE YOU USE, KEEPING WHAT WORKS! 

Key Kanban Points: 

• Kanban helps overcome inertia 

and resistance to change 

• Kanban is less prescriptive 

than Agile or classic Project 

Management 

• Kanban requires no roles (but 

does not eliminate them) 

• The Kanban team approves its 

own changes (where practical) 


2. VISUALIZE THE 

WORKFLOW


VISUALIZE 

THE 

WORKFLOW 

A Kanban board 

visualizes your process as 

simply as possible. And it 

lets you know if your WIP 

is progressing as it should. 

Kanban operates on the 

following assumptions: 

1) Humans are, at their 

core, visual thinkers 

Kanban operates on the idea that you can only control 

what you can see. So, you must see your workflow, from 

start to finish. And, you must see where a particular work 

item is in that workflow. Is it in Development? Testing? 

Has it been delivered? 

You can also begin to see bottlenecks. Why are there 

five features in Testing but none at the later stages (like 

delivery to the customer)? What can we do differently to 

improve this flow? 

You can control the flow by limiting the WIP. Perhaps 

you allow only two features in Development at any one 

time. If so, then Testing is unlikely to be bogged down. 

You can change the process of workflow. Perhaps 

adding automated testing or TDD will improve the flow 

of the work. 

Ideal is a nonstop flow of features, from conception 

through delivery. 

2) You can’t control what 

you can’t see 

A Kanban card has all the 

visual indicators you need 

to know where a work 

item is; in other words, 

where the flow is working 

smoothly and where it is 

backed up and needs your 

attention. 



MAP THE PATH 

OF THE WORK 

Create a value stream 

map (VSM), which 

follows the creation of 

value for a customer. 

The map should follow 

a work item, like a code 

requirement or feature, all 

the way through design, 

development (in the case of 

software), and production 

(for manufacturing) 

through to delivery and 

customer acceptance. 

HOW DO YOU GO ABOUT 

CREATING A VSM? 

Capture the as-is process. 

For now, you are trying to draw a 

realistic picture of your process. 

Rather than asking people what the 

process is (they will sanitize or 

idealize), ask what steps a finished 

piece of work went through from 

start to finish. Start with: What 

happens first? After that keep 

asking: Then what happens? 

Chances are, you’ll begin to identify 

some inefficiencies, surprises, and 

downright strange behavior. 

Perhaps (and this is a real case) 

you’re a game developer and the 

validation department runs every 

functionality past a mailroom 

attendant, reasoning that he’s an 

average Joe and if he can use it 

then it’s well designed. Resist the 

temptation to redesign the value 

stream now—just map it. 

Look for handoffs rather than 

steps. 

Each handoff from one person or 

group to another represents a state 

in development on your Kanban 

board, represented by a column. 

Likely, there is a handoff between 

Development and Validation; so, 

each should be represented in a 

state. While Unit Testing is a step in 

the process, a developer typically 

performs it, so, there is no handoff; 

hence, Unit Test is not a state on 

the Kanban board. 

Once again, begin with requirement 

creation (the idea stage) and finish 

with delivery to the customer. Do 

not attempt to capture every 

interaction in your customer 

relationship (for example, 

invoicing)—just those that make 

development flow. 

Use simple tools. 

Some elaborate and elegant 

software tools are available to 

create VSMs. You may be tempted 

to use a classic project 

management tool and Gantt chart. 

But think simply—like pens-and-aflipchart 

simple or sticky-notes-ona-wall 

simple. The spirit of Kanban 

is, after all, to visualize, simplify, and 

drive out unnecessary complexity. If 

you really must use a software tool, 

a diagramming tool like Microsoft 

Visio is sufficient. 

?KM

Think linearly. 

VSMs are literally drawn in a 

straight line from conception 

through delivery. There will be 

some loops in the process (for 

example, a return from validation 

back through development) 

and interdependencies, but the 

stream itself should be straight. 

Limit yourself to your own 

domain or purview. 

That is, focus only on the flow of 

work in your department or which 

you control. Other steps may be 

outside your domain and scope. As 

the organization matures in Kanban, 

you may visualize those areas in the 

Kanban system, but save that 

for later. 

Persist! 

You may find this value stream 

mapping tedious and frustrating at 

first. It is, after all, a new skill and 

fresh way of looking at the world. 

Don’t be tempted to skip over it and 

create your Kanban board first. 

Resist that temptation, else, you risk 

throwing out good process with 

bad. You also risk alienating the 

people along your value stream. A 

basic tenet of change management 

is that you need “buy in” from team 

members to avoid failed change. 

Which leads us to . . . 

Meet resistance with assurance. 

Likely, as you investigate the path of 

work, you will meet with resistance 

and suspicion. It is natural for 

people to wonder “Am I going to be 

in trouble if they don’t like what I tell 

them?” “Are they going to figure 

out that I’m unnecessary and get rid 

of me?” “Will I look incompetent 

if I don’t know exactly what the 

process is in my department?” 

The team must trust the process. In 

fact, the fifth principle of the Agile 

manifesto suggests that you should 

“build projects around motivated 

individuals” by “[giving] them the 

environment and support they 

need, and trust them to get the job 

done.” Make certain that team 

members along the value stream 

understand that the objective is not 

to “fix the process.” You may not 

change the process at all! Rather, it 

is to get a handle on the process 

and make sure that it works as 

smoothly and efficiently as it 

possibly can. Let them understand 

that Kanban is state-of-the-art 

software engineering used at, 

among others, Microsoft. 

KEEP IT SIMPLE. 

SOME OF THE 

MOST EFFECTIVE 

KANBAN BOARDS 

WE’VE SEEN HAVE 

BEEN STICKY 

NOTES ON A 

WHITEBOARD. 



VISUALIZE 

THE PROCESS 

ON A KANBAN 

BOARD 

Now, turn your VSM into a 

Kanban board. 

Just like your VSM, your Kanban board will be linear—an array of columns (or states), 

progressing from left to right, describing the flow of the work. 

Use simple tools. 

Here again, you will find elegant 

software tools and elaborate 

solutions for Kanban. And here 

again, think simply instead. 

A Kanban board should be visible, 

clear, and available to the entire 

team. If the team is co-located, then 

use a corkboard with pushpins and 

cards or, better yet, a whiteboard 

with sticky notes. If your team is 

virtual, then perhaps you do need 

an electronic system on your 

company’s internal cloud or wiki. 

It is best to start with something 

impermanent, like a whiteboard, 

using columns drawn with erasable 

markers. Later, when your Kanban 

board is more finalized, you can 

invest in vinyl tape and a more 

elegant presentation. 

Start with broad strokes. 

You want a not-too-simplistic, 

not-too-detailed representation 

of your workflow. At its simplest, 

your workflow is as follows: 

Backlog > In progress > Done 

But, that is too simple. “In progress” could be anywhere along the value 

stream, from specification to QA. And what does “Done” mean? Sitting in 

some outbox or delivered to the customer? 

A more realistic, inclusive representation might look like this: 

Backlog > Analysis > Development 

> Validation > Deployment 

And the finished Kanban board, with each of those states represented, 

looks something like Figure 1:

BACKLOG ANALYSIS DEVELOPMENT VALIDATION DEPLOYMENT 

Figure 1 A Simple Kanban Board 

Isn’t that just an Agile task board? 

It looks like one. But a Kanban board differs from an Agile task board in that it includes limits (more on 

that in the next section). So, let’s dig a bit deeper. 

A simple test 

If your Kanban board truly represents your process, you should be able to place any work item from your 

current project somewhere on the board. Try it! If you cannot place all of the features, then you have 

missed a step in your design. Perhaps the step is unnecessary or only occasionally necessary. In either 

case, you are charting your actual process and must add the step to your Kanban board. 



Vs 

WIP VERSUS 

DONE 

Now that you have defined 

your states, divide each 

of the states (except 

Deployment) into two 

columns. 

Divide the backlog into To Do and Ready columns. Later, you will define criteria 

a work item must meet to be ready for the cycle. Divide the remaining states into 

WIP and Done columns (see Figure 2). By doing so, you enable workers at the 

downstream state to know exactly which items to pull from upstream; those items 

are in the Done columns (called “buffers” or queues). 

Of course, that queue is more obvious on a manufacturing floor where physical 

goods stack up than it is on a server, but a Kanban board visualizes the queue. 

BACKLOG 

ANALYSIS DEVELOPMENT VALIDATION DEPLOYMENT 

TO DO 

READY 

IN 

PROGRESS 

DONE 

IN 

PROGRESS 

DONE 

IN 

PROGRESS 

DONE 

IN 

PROGRESS 

Figure 2: A Kanban board that includes buffers (“Done” columns).

No buffers, buffer limits or slack time 

You may have heard of “buffer limits” on the Done 

columns. The idea is to set limits on the Done 

columns and to halt work while people in the next 

state catch up. 

This practice has fallen out of favor as being 

unnecessarily complex and an impediment to flow. 

The general thinking in the Kanban community is that 

it is a “no-brainer” to have a single WIP limit that spans 

work in progress and work that is done. 

Key Visualization Points 

• Use simple tools 

• Follow the code 

• Be accurate 

• Think linearly 

• Make no changes (yet) 

• Do not proceed until this is finished 

• Queues, buffers, and slack time represent more 

WIP and longer cycle times 

• Meet resistance with assurance 

Ideally, there are no buffers or slack time 

A queue or buffer between states (those Done 

columns) absorb variation. It allows that some work 

items will be done more quickly, while some will 

take longer. 

Once you’ve mastered Kanban, you can begin to set 

policies for the right level of WIP so that there is 

effectively very little buffer or slack time. To the degree 

you can minimize buffers and slack time, you have 

more continuous flow and a better system. 

While you are learning and mastering the techniques of 

ensuring continuous flow, limit buffers and slack time 

to the extent that is practical. Treat that extra WIP as a 

waste to be avoided. Hold fast to the ideal that the 

time between when your work starts and is done 

should be as short as possible. 

Picture the customer making a request and then 

waiting in your lobby until it is done. 


3. LIMIT WIP


LIMIT WIP 

The goal of limiting 

WIP is to limit 

demand to match 

capacity. 

Limiting WIP in each state to or near its capacity ensures 

continuous flow. That enables you to deliver new value quickly 

and creates a rapid, continuous flow of value, from a customer 

request through delivery. 

Simply put, there is a limit to the capacity of your system. 

Think of your system as a ¾-inch garden hose with a capacity of 23 gallons per 

minute. Your upper limit is 23 GPM no matter what you do. All the pressure in the 

world will not increase the hose’s capacity, but it will eventually burst the hose. 

Your team has its limits as well, and higher pressure does not increase output. 

Quite the opposite. 

Dumping all the software development work into your system and crying “Quick!” 

does not guarantee that it will be done in a timely manner. A developer with 22 

work items can only work on one at any moment. Rather than finishing them one 

by one, the developer may instead try to multitask and switch among the 22, but 

none of them is actually delivered on time (an estimated 20 percent of time is lost 

“context switching” between tasks). Additionally, too much WIP boosts the defect 

rate, which, in turn, lengthens the average cycle time. And no one wants to work 

on “bugs”! 

WIP limits reduce errors and time wasted in switching 

between tasks. 



KANBAN 

MAKES WIP 

OVERLOAD 

IMPOSSIBLE. 

In Kanban, you use WIP 

limits at every step of the 

development cycle based 

on the capacity to deliver 

the work in progress. For 

example, a team may 

specify two work items per 

developer and one request 

per tester. In this way, 

work progresses along 

the Kanban board using a 

pull system. Only when a 

downstream step or state 

is below its WIP limit (e.g., 

having two work items 

when its WIP limit is three) 

may the workers in that 

state pull a task from the 

upstream Done column. 

And, it shortens cycle time 

We’ve mentioned cycle time, but 

let’s dig a little deeper. 

Cycle time is the length of time 

between when work begins on a 

request and when the item is 

delivered. 

Little’s 

Law 

Ideally, your cycle time is fairly 

predictable. You can tell a customer, 

“We can deliver that amount of 

work in two weeks” and be spot on. 

It is easiest to predict cycle times 

accurately when features are about 

the same size or at least of an 

average size. 

Cycle Time = 

In software engineering, it works like this: 

Cycle Time = # of work items in process (WIP) / Average Completion Rate 

Cycle time is a function of Little’s 

Law, a mathematical theorem that 

applies to queues. Fast-food chains, 

for example, use it to determine 

how many workers they will need 

to handle the average lunch rush. 

WIP 

Throughput per unit 

of time 

If, for example, your customer comes to you with six items and your team completes, on 

average, three items per week, then: 

6 Items / 3 Items per week on average = 2 weeks Cycle Time 

Recall that there are several hands-on ways to improve cycle time, including the following: 

• Reduce the number of work items in process. Simply put, you can deliver one item 

sooner than you can deliver three. And, you reduce the risk of delivering all three items in 

a batch. 

• Improve average completion rates by: 

−− 

Reducing rework (usually considered a waste) 

−− 

Identifying and removing typical blockers or bottlenecks 

−− 

Identifying and analyzing work items that are too large (labor intensive)

DELAY COSTS 

Limiting WIP and 

shortening cycle times 

ensure a continuous 

flow of value. They also 

reduce the costs of 

delay (COD). 

$ 

$ 

$ 

$ 

$ $ $ 

There is an inherent cost of delay (COD) associated with every 

work item. These costs are economic, and key among them is 

the cost of decay—the longer a work item is in development, 

the higher the likelihood that changes will be needed and the 

greater the scope of those changes. 

Some advanced software engineering organizations have 

accountants on staff to develop profit-and-loss (P&L) 

statements for each project. But there are costs as well in 

brand share, customer esteem, and team morale. You are 

largely guaranteed to reduce costs of delay by reducing WIP 

and by using the above methods of assigning urgency/class 

of service, be those costs in dollars, customer esteem, or 

team morale. 

You can calculate dollar values for costs of delay, but those calculations 

are complex and beyond the scope of this text. Besides, with your 

business savvy, you know a high-cost item when you see one. 

If you had the bandwidth to work on only one item, would it be a 

blocker bug on your current release or the improved user interface 

of your next release? 

Conventional wisdom is that the sooner you introduce a feature, 

the sooner you profit from it, but there is never a $0 cost of delay. 


ASK YOUR 

TEAM TO SET 

ITS LIMITS 

Setting WIP limits is both 

an art and a science. 

Initially, ask your team to set its own WIP 

limits: After all, it will be their job to enforce 

the limits and complete the work. 

Your six-person development team might 

decide that it needs two developers per user 

story; so, its WIP limit would be three. Your 

validation team may calculate that it works 

faster (based on its average output) and can 

manage a higher WIP limit of five. 

Consider two different approaches that this 

team might use in setting their WIP limits: 

The Conservative Approach: Set WIP limits just 

loose enough for your current workflow to continue 

unhindered; then identify your bottleneck and adjust 

one limit at a time. 

The Radical Approach: Set WIP limits on activity 

columns tighter than you expect your system will be 

able to handle and buffer each stage; then observe 

where work builds up, and gradually loosen until work 

flows through the system.

ALLOW FOR 

ADJUSTMENTS 

Both approaches require 

some experience, so don’t 

expect to get it right the 

first time. 

There is no final consensus as to which one is better, but 

setting limits with your policies in mind seems to work in 

both circumstances. 

Kanban is a self-correcting methodology. If after several 

Kanban meetings you notice that Customer Acceptance begins 

every day with an empty WIP column, then its WIP limit could 

be higher. If bottlenecks frequently occur in Development, then 

perhaps its WIP limit needs to be lower and more developers 

must be assigned to each story or work item. 

Just as the team made the initial decision about WIP limits, 

it should also make the decision to change them. 

Key WIP Limit Points 

• A continuous flow of work is represented by low Cycle Time 

• Cycle Time can be decreased by limiting WIP 

• Reducing WIP reduces the number of defects 

• Allow the team to set its WIP limits 


4. MEASURE AND 

MANAGE FLOW 

Experience has taught me how important it is to just keep going, focusing on running fast 

and relaxed. Eventually, it passes and the flow returns. It’s part of racing. 

- Frank Shorter


MEASURE 

AND MANAGE 

FLOW 

So far, Kanban may feel informal and off the cuff. You are 

writing on sticky notes, after all. Now it becomes a bit more 

structured, with metrics to measure flow and improvements 

and intervals that ensure continuous flow. 

All the classic change methodologies, like Lean, Total Quality Management 

(TQM), and Six Sigma use metrics. Kanban is no different. Let us repeat the 

key objectives of Kanban: 

1) Reduce cycle time 

2) Increase workflow 

You will need hard measures of cycle time and workflow 

to make any lasting change. 

Also, true smooth, continuous flow does not simply happen, although 

Kanban ensures that it happens more naturally. Flow must be actively 

managed, for example, by recognizing and swarming a bottleneck until 

flow is restored. 

It helps to have some predictability, some expectations of flow. Setting a 

release cadence at a regular interval fosters trust with the customer and 

gives the team a feeling of accomplishment. 

Note: 

A release cadence should be applied to new work that has completed the 

development cycle—not customer support bug fixes (which should be 

completed and released immediately) or when Kanban is used by a nondevelopment 

team 

0 1 2 3 4 5 6 7 8 9 10 



MEASURE 

PERFORMANCE 

WITH METRICS 

Perhaps the word “metrics” 

elicits a groan from you 

and your team. It is a 

loaded word that signifies 

accountability. Typically, 

management demands 

metrics and then demands 

explanations if they don’t 

like what they see. 

That’s not the way to think. 

Metrics are tools for the Kanban team. The team 

generates its own metrics and then uses them to ensure 

continuous improvement. 

Think of metrics not as a chore, but as an enabler. 

Metrics enable a software engineering organization to 

recognize its own excellence and “improve its game” 

(by improving the processes). 

In advanced Kanban, you would concern yourself with 

both financial and production metrics. Financial metrics 

include investment, throughput, and operating expense 

(called I, T, and OE). But first things first. Measuring and 

improving production metrics will improve those 

financial metrics automatically. 

That brings us back to management. We say that 

metrics are for the team’s use, but management must 

have access to them too. After all, Agile development 

teams are treated as a profit center, and any profit 

center must justify itself through continuous 

performance. Flow and cycle time metrics are proof of 

that performance. 

Do not succumb to “Metrics Madness”! Too many 

metrics drive the perceived failure of Six Sigma. 

Metrics take time to collect and analyze. Reinertsen 

in Managing the Design Factory observed that 

information differs in value, and we must generate 

information of only the highest possible value. Because 

Kanban operates on the principles of maximizing value 

by maximizing flow and minimizing cycle times, begin 

your mastery of Kanban by focusing upon production 

metrics. 

As you advance, you can master defect rate metrics, 

even financial metrics like operating expense. But for 

now, the Kanban team should concern itself with only 

three—throughput, cycle time, and cumulative flow. 

In Kanban, metrics are not a liability or a 

chore. They are like a lap time or golf 

score—an opportunity for the team to 

prove itself and improve itself. 

Throughput 

Throughput is very easy to measure. 

Throughput = Items removed/Time 

Think of the Kanban board as a conveyor belt, with 

finished work picked off the conveyor at the end. How 

many items get picked off (and disappear from) your 

Kanban board in a week? That is your throughput. 

Most software Kanban teams measure throughput in 

one-week increments. A day is typically too short, and a 

month is too long. But if measuring per day or month 

suits your organization best, by all means, do so. 

Ignore the size of or circumstances surrounding the 

work items when you measure throughput. To use the 

popular phrase, throughput “is what it is,” and it may be 

ten items this week and six next week and eleven the 

week after. Variation is natural. 

As time passes, if you find that throughput is 

unpredictable and varies widely, then you may wish to 

perform some more sophisticated math that takes into 

account T-shirt size, type of work, and so forth. 

But save that for later. For now, and as weeks pass, you 

are simply accumulating data. Your average throughput 

will become more accurate with each week that you 

measure it.

Cycle Time 

Recall that the cycle time of a work 

item begins when the actual work 

begins and ends when a task is 

finished. 

Cycle time metrics help you 

determine if process improvements 

are yielding the expected results. 

They also help the team make 

realistic time commitments; for 

example, writing Service Level 

Agreements with its customers (we 

explore service level agreements in 

Chapter 4, “Make Process Policies 

Explicit”). When the team can 

commit to delivering six new 

features with an 85 percent level of 

confidence, based on historic cycle 

time data, then your process is 

yielding predictive results. 

Figure 4 depicts an even simpler 

form of cycle-time diagram. In this 

instance, we still measure cycle 

time, in days along the Y-axis, but 

the cycle time of each work item as 

it is done is seen on the X-axis as 

individual work items, in order of 

being done. Here again, as 

processes improve, cycle times 

should improve as well. You won’t 

see a perfectly steady downward 

trajectory because throughputs 

and work item sizes are not 

absolutely consistent. Still, you 

should see a general downward 

trend. The average cycle time in 

this diagram is just above six days, 

a considerable improvement over 

the nine days at the beginning of 

the project. 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Figure 3: A cycle time diagram that charts averages 

10 

1 

2 

3 

4 

5 

6 

7 

10 

DAYS 

8 06/05/2013 

9 10 11 12 

13 

14 

A simple cycle-time diagram is 

depicted in Figure 3. This example 

shows the average cycle time in 

number of days over the course of 

the project. Ideally, as more work 

items flow more smoothly, the 

average cycle time decreases. 

Spikes in average cycle time 

indicate inefficiency, such as 

frequent expediting or rework, and 

signals the need for a process 

improvement. 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

Figure 4: A cycle time diagram charting each work item as 

it is completed 



CUMULATIVE 

FLOW 

DIAGRAMS 

(CFDS) 

A cumulative flow 

diagram (CFD) is a 

simple area graph that 

depicts the quantity 

of work in a given 

state, measured at 

regular intervals. A 

week is typical in Agile 

software development. 

A CFD is a powerful tool that tracks 

and measures workflow. It visually 

represents several measures at once, 

including input (number of work 

items), throughput, WIP, and cycle 

time. It is updated once a week (or 

more) and used to see how WIP and 

lead times progress over the life 

cycle of development. Plenty of 

software tools are available, but 

most new to Kanban use the Area 

Chart functionality in Microsoft 

Excel. Figure 5 depicts two 

variations of a CFD. The first shows 

the three most obvious states in 

Agile software development, being 

Total Features 

140 

120 

100 

80 

60 

40 

20 

0 

In Backlog, In Progress, and Done. 

The second represents all the states 

on your Kanban board, such as: 

• Analysis 

• Development 

• Validation 

• Customer acceptance 

As time goes on, the number of 

completed items rises. The work in 

progress stays fairly minimal for 

each state and never exceeds the 

cumulative WIP limits set for 

the system. 

Total Features 

140 

120 

100 

80 

60 

40 

20 

0 

05/11 

12/11 

19/11 

26/11 

03/11 

10/12 

17/12 

24/12 

31/12 

07/01 

14/01 

21/01 

28/01 

04/02 

11/02 

18/02 

25/02 

04/03 

11/03 

18/03 

25/03 

01/04 

Date 

Backlog In Progress Done 

05/11 

12/11 

19/11 

26/11 

03/11 

10/12 

17/12 

24/12 

31/12 

07/01 

14/01 

21/01 

28/01 

04/02 

11/02 

18/02 

25/02 

04/03 

11/03 

18/03 

25/03 

01/04 

Analysis 

Customer Acceptance 

Date 

Development 

Validation 

Figure 5A: A simple CFD, and one that includes 

each state. 

Figure 5B: All the states on a Kanban board


4/8 

4/9 4/10 4/11 

4/12 4/13 4/14 4/15 4/16 4/17 4/18 4/194/20 4/21 

INTERPRET 

YOUR CFD 

BACKLOG SIZE 

WORK REMAINING 

30 

25 

Learning to interpret 

a CFD is not difficult. 

Figure 6 offers an 

illustration of how 

different aspects of 

the graph are used to 

generate metrics. 

NEW ITEMS 

CYCLE TIME 

LEAD TIME 

WORK IN PROGRESS 

20 

15 

10 

5 

0 

Figure 6: Deployed Interpreting a CFD. 

Pre-Production Testing 

Your velocity over time is defined by the “Done” area, while WIP is 

indicated 

Dev/Test 

by the space 

Cycle 

between this line 

Choosing 

and the “Backlog” 

& Defining 

line. 

• A sign that a bottleneck is occurring would be an increase in the width 

of a portion of the WIP area (seen at a couple of points on the graph). 

• A clear sign that work is exceeding capacity in your system is if the 

pitch of the “Backlog” area is steeper than the “Done” area (4/17–4/18). 

• Your current best estimate of a final release date would be estimating 

the point at which the gradients of “Backlog” and “Done” intersect (not 

seen on this graph). 

• You can also determine from the diagram your Average Cycle Time and 

Quantity in Queue. 

Key Metrics Points 

• Metrics are created by the team and for the team’s use 

• Focus first upon value-driven metrics of flow and cycle time 

• A downward-trending cycle time indicates improvement 



MANAGE 

FLOW BY 

RELIEVING 

BOTTLENECKS 

A bottleneck is the point 

in your process with 

the lowest production 

rate. Bottlenecks must 

be actively managed. 

They interrupt flow 

and increase cycle 

times, meaning that 

they decrease the value 

you deliver, both for 

your customer and the 

organization. In short, 

they cost money. 

In theory, for every one hour 

that a bottleneck exists, one 

hour of production is lost at 

every stage downstream. 

So the cost multiplies. 

But once you relieve the 

bottleneck, you have 

generated multiple hours 

of value-added work 

downstream. 

A bottleneck is immediately visible 

on your Kanban board. Look for the 

following: 

• Work items that are not moving 

over time, and 

• Vacant space. Perhaps there 

is no work in the Validation 

column because it has no 

finished work to pull from 

Development. 

Because Kanban teams check in at 

least once daily at the Kanban 

board, any bottleneck you find 

should be less than one day old. 

This allows you to find a solution 

before a large amount of partially 

completed work builds up. 

The solution is typically to “swarm” 

the blockage—to reallocate 

resources to relieve the bottleneck. 

Swarming sounds pretty 

disorganized, but it is not. 

Choose carefully who swarms. 

• Look for a skills gap. Perhaps a 

particular developer lacks the 

skills to complete a given work 

item that another developer has. 

• Relieve the bottleneck of some 

of its workload. Can a developer 

or a QA tester “swim upstream” 

for a few hours to perform some 

tasks in Analysis? 

• Let it be. Do nothing. If those 

in the bottleneck are aware of 

the situation and can resolve it 

within a few hours, no further 

action is required. 

It is important that your team 

understands that bottlenecks are 

not a failure. In the classic Theory of 

Constraints set forth by Eliyahu 

Goldratt in his 1984 book The Goal, 

bottlenecks are dynamic.

BEFORE 

At any one time, some point in production moves slower than the rest. 

The best-run systems do not have more than one bottleneck at a time, and 

removing one bottleneck reveals another, allowing you to improve the process. 

AFTER 

But if the bottleneck is consistently 

at one point in the value stream, 

then you have a static bottleneck. 

You might observe on your CFD 

diagram that the width of a 

particular state (like Developed or 

Tested) widens over the course of 

the project. This signifies high 

inventory at that step. These 

historic bottlenecks signal the need 

for some process improvement or 

more permanent solution, like – 

• Adjusting WIP limits 

• Reducing batch sizes 

• Adjusting the work balance, for 

example, with more stringent 

standards at the upstream step 

such that work in the bottleneck 

step is easier and flows faster 

• Adding staff, which raises 

operating expense (OE). But 

if your Development group is 

operating at capacity and is 

a consistent bottleneck, then 

perhaps it simply needs more 

capacity to deliver more value. 

Bottlenecks are not a sign 

of failure. At any time, one 

part of the process will move 

slower than the rest. But if 

the bottleneck is consistently 

in the same place, the 

process needs adjusting. 

Key Bottleneck Points 

• The value a system delivers is 

limited by its bottleneck 

• Bottlenecks do not indicate 

failure 

• Dynamic bottlenecks signal the 

need to redeploy resources 

• Static, unmoving bottlenecks 

signal the need for a permanent 

change 



ENSURE 

FLOW WITH 

CADENCES 

You may also rely 

upon regular intervals, 

called cadences, for 

planning, delivery, 

and retrospectives. 

Like the daily standup 

meetings, these 

ensure that each work 

item gets the attention 

it requires; in other 

words, it is prioritized, 

put into the queue, 

troubleshot, and 

approved. 

Cadence is a pace—a kind of 

heartbeat, or drumbeat, for 

delivering work. Have you 

ever heard the coxswain of a 

rowing team calling, “Stroke, 

Stroke, Stroke”? 

That is a cadence. The songs 

that soldiers and sailors use 

in formation to pace 

themselves (“Superman’s 

the Man of Steel/Ain’t no 

match for a Navy Seal”) 

are cadences as well. Agile 

software development with 

its time-boxed iterations 

(typically one to four weeks) 

establishes a cadence. 

Three cadences typical of both 

Agile and Kanban are as follows: 

• Planning cadence 

• Delivery cadence 

• Review/retrospective cadence 

Cadence cautions 

Cadence is more critical as a 

Scrum practice than in Kanban. 

A team that has practiced Scrum 

likely has already established its 

cadences and may be ready to 

shed some of the structural walls of 

Scrum. It may have established a 

once-weekly retrospective meeting 

only to conclude that the meetings 

pull the team away from generating 

value and do not contribute to 

their growth. 

True, too, cadence is more 

practicable with Scrum’s timeboxed 

iterations and MMFs of 

roughly equal size. 

Still, cadence has its charms, 

among them that people are 

generally more productive with 

some regular structure and rhythm. 

As you begin your Kanban journey, 

experiment with a delivery cadence 

and a retrospective cadence. 

Delivery cadence 

The delivery cadence is the interval 

by which the team releases features 

or stories to the customer. The 

typical delivery cadence is weekly 

or biweekly. Yes, there will be cases 

of expedited delivery (e.g., to 

manage a significant bug). 

But then it is important to return 

to the regular delivery cadence. 

Why not simply release the entire 

job at once? Or in the spirit of 

continuous flow, toss each work 

item over the wall as it is done. 

Because both are less efficient than 

they appear to be.

Every batch of features includes 

both holding costs and transaction 

costs. Holding costs include 

erosion of business value, 

outdated feedback, reduced 

user participation, and so forth. 

Transaction costs include the sheer 

stop and start of delivery and 

piecemeal accounting labor 

(among others), plus, too-frequent 

feedback on the part of the 

customer that creates churn. 

There are complex economics 

involved in holding and transaction 

costs, which Reinertsen details in 

The Principles of Product 

Development Flow. 

A weekly or biweekly cadence 

achieves a balance between the 

two costs. For a batch of twentyfive 

features, it reduces the number 

of transactions to, let us say, 

seven transactions. 

The customer participates with 

feedback and change requests 

more regularly (but not 

ceaselessly), which ensures 

more continuous flow. 

Besides, a regular delivery cadence 

builds trust with a customer, who is 

assured that you are hard at work 

delivering “their” product. 

Consistent delivery fosters 

trust with customers. And, 

it reduces holding costs. 

Review/retrospective cadence 

The review/retrospective cadence 

sets a regular interval (typically at 

the end of a workweek) by which 

the team meets to reflect upon the 

week. Using the metrics they chose, 

perhaps the CFD and cycle-time 

diagrams, they ask what went well, 

what went poorly, and how they 

can revise the workflow for 

improvement during the upcoming 

week. The result is iterative, 

incremental improvement of both 

the product and workflows, 

including the team’s ability to 

work collectively. 

Why not wait until the end of a 

project? Because just as it is more 

efficient to work on a finite number 

of work items at a time, it is easier 

for team members to apply their 

full attention and ingenuity to 

incremental improvements to the 

workflow as things unfold. 

Key Cadence Points 

• A cadence is a kind of heartbeat 

for planning, delivering, and 

reflecting upon work 

• Cadences are independent of 

one another, but regular 

cadences of once weekly are a 

good practice for new Kanban 

practitioners 

• A delivery cadence balances out 

transaction costs, while 

fostering trust with the 

customer 

• A retrospective cadence 

ensures that incremental 

process changes are 

recognized and made 


5. MAKE PROCESS 

POLICIES EXPLICIT 

If you cry “forward,” you must make clear the direction. 

- Anton Chekov


MAKE 

PROCESS 

POLICIES 

EXPLICIT 

Policies are not 

restrictive in Kanban— 

they are freeing. They 

enable you and the team 

to focus upon valuecreating 

work because 

they are clear definitions 

of how to prioritize 

work and when work is 

considered done. Policies 

protect the team from 

overwork by specifying 

WIP limits. The result 

is a continuous, 

uninterrupted flow of 

work . . . and, of 

course, value). 

Unless the mechanism of software 

development is made explicit, it is 

difficult to improve that 

mechanism. “Any discussion of 

problems tends to be emotional, 

anecdotal, and subjective,” wrote 

Anderson, where an explicit 

understanding allows a more 

rational, objective discussion, 

and with it, a greater chance 

of consensus. 

is fluid and open to change. It 

has to be if we are to improve the 

process. We begin by saying, 

“This is the policy,” and then we 

ask, “How can we improve it?” 

Following is a short list of 

policies to set as you begin 

your Kanban journey. 

Frequency of planning & stand-up 

meetings 

Earlier, we discussed the delivery 

cadence. The planning cadence is 

the interval by which the team 

leaders and Product Owner meet to 

prioritize features and release them 

to the team. Advanced Kanban 

teams may rely upon the “plan on 

demand” technique of gathering 

the stakeholders when a number of 

slots are empty in the input queue. 

For now, set a planning cadence, 

which involves short meetings at 

the beginning of the workweek. 

For now, hold a stand-up meeting 

at the beginning of each day, and 

follow a tight script like Scrum. 

Make it the type of stand-up 

meetings typical of Agile software 

development, time boxed for fifteen 

minutes maximum. A rule of thumb: 

discourage folks from bringing food 

or sitting down; otherwise, your 

meetings will be prone to focus 

more on social and political content 

than the core topic of planning. 

Follow this agenda: 

1. Update the Kanban board to the 

current status for all work items. 

2. “Read” the board, looking for 

new items, bottlenecks and 

overloaded areas, and items 

that are date at risk or customer 

urgent. Read the board from 

right to left, starting with the 

items that are closest to done. 

This practice reinforces Flow 

thinking and the idea of 

minimizing WIP. It also 

communicates that the most 

important items are the items 

closest to delivery. 

3. Create specific plans to handle 

those work items, answering 

these questions: 

a. Who is working on the item? 

b. Does that person need 

assistance to finish the item 

on time? 

c. If the item is blocked, what can 

the team do to unblock it? 

At the end of the meeting, you 

should have rearranged work items 

such that there is no WIP capacity 

left over; each state is filled to its 

WIP limit—a state that was below 

its WIP limit has pulled work from 

upstream all the way down the line. 

It may be tempting to hold 

meetings once a week, but resist 

that temptation. You will simply 

spend more time updating the 

board. And, you run the risk that 

bottlenecks and date-at-risk items 

will age another day, becoming 

more critical. Finally, it can delay 

team members below WIP limits 

from pulling work. 

Kanban eliminates much 

of the debate, deliberation, 

and finger-pointing of 

software engineering. 

WIP limits, Priorities, and 

Definitions of Ready and 

Done are well thought out 

before items are placed on 

the board and inarguable. 



DEFINITION 

OF WORK 

TYPES & 

WORK ITEMS 

Earlier, we “Visualized 

the Workflow.” We 

must also visualize 

work types and work 

items. Each work item 

will have its own card, 

perhaps a sticky note. 

And, each card or note 

will have some key 

pieces of information. 

Use a color key to visualize the type of work by 

the color of the card or sticky note. You may, for 

example, choose blue sticky notes for maintenance 

items and pink ones for defects. 

Some typical work items that Anderson named in 

Kanban: Successful Evolutionary Change in Your 

Software Business are shown below. 

• Requirements 

• Features 

• User stories 

• Use cases 

• Change requests 

• Defects 

• Maintenance 

• Refactoring 

• Bug 

• Improvement suggestion 

• Blocking issue 

You may choose instead to identify work by the source, 

for example, customer request, field sales request, or 

strategic planning requirement. 

An ultrasimple method is to divide work between 

improvement and maintenance. 

Whichever convention you use, try to limit your types 

to two or three and five at most. 

Other information: 

• Place these pieces of information on four agreedupon 

points in the card or note. 

• Title and description (the user story). 

• Due date, if any 

• Start date, being when you begin to clock 

cycle time. 

• Relative “size” of the item. A popular convention 

is to estimate the “T-shirt size” of a work item (the 

estimated lead time needed to complete it). An 

extra small (XS) item might have a lead time of less 

than a day, while an extra large (XL) takes three 

weeks, a large (L) two weeks, and a medium (M) 

one week. 

So, a finished Kanban work item might look like 

Figure 7: 

DEBUG CONTACT 

BACKUP 

Fix backup from Excel failure 

DUE: 4/12/2014 

START: 4/6/2014 

S 

Figure 7 Each work item has a card or sticky of its 

own with all the information the team needs

DEFINITION 

OF READY 

Of course there are 

innovative, aspirational, 

speculative features in the 

queue—there should be! 

These drive innovation 

in your organization. 

But the team must not 

be tasked with a wild 

idea for which there is 

only lackluster support, 

little understanding of 

customer value, or simply 

a lack of team skills 

to execute. 

Establish a definition 

of ready—hard criteria 

that must be met before 

a work item moves 

from the backlog to 

become WIP. 

The definition of ready is a short 

checklist of criteria for a work item 

to move from the backlog and enter 

the cycle. It ensures that the team 

has all the information it needs to 

complete the work and prevents a 

backup mid-cycle. 

The team is best suited to outline 

the characteristics of a work-ready 

item. Some typical elements of a 

definition of ready include the 

following: 

• A contact name 

• The contact availability at the 

time the work begins 

BACKLOG 

• Item groomed – 

discussed with 

the team 

• Acceptance test 

cases 

• Estimated 

• No blocking issues/ 

dependencies 

TO DO 

3 

READY 

• Discussion 

with user 

• Solution outline 

discussed with 

developer and 

with user 

• Some written specification 

of the demand (the user 

requirement) 

• Clear validation criteria 

• Some idea of who on the team 

has the skills to execute the idea 

Definition of Done (DOD) 

For each state on your Kanban 

board, ask the team to write a 

Definition of Done (DOD); then, 

write those definitions at the 

bottom of each column on your 

Kanban board (as in Figure 8). 

3 

4 3 3 

ANALYSIS DEVELOPMENT VALIDATION DEPLOYMENT 

IN 

PROGRESS 

DONE 

• TDD 

• CI Passes 

• Acceptance test 

cases verified 

• User docs updated 

IN 

PROGRESS 

DONE 

• Running in staging 

environment 

• 24 hour soak 

• User docs validated 

IN 

PROGRESS 

DONE 

The DOD is the condition that must 

be met before a work item can be 

pulled into the next state. 

Ask the team to think in absolutes. 

DoD is the team’s quality statement 

that ensures a feature is 100 

percent developed and error free. 

Keep DoDs simple. For example, a 

DoD for Development might be: 

• Code clean and checked 

• Integrated and regression tested 

• Runs on user acceptance testing 

(UAT) environment 

• Installed in 

production 

• Running with use 

and no issues for 

24 hours 

• Comm with users 

complete 

IN 

PROGRESS 

Figure 8 Definitions of ready are spelled out at the bottom of each Kanban state © Copyright 2012 Gear Stream, Inc. 39


EXPLICIT WIP 

LIMITS 

BACKLOG 

6 2 

2 3 4 

CUSTOMER 

ANALYSIS DEVELOPMENT VALIDATION ACCEPTANCE 

DELIVERY 

4 

A simple way to make 

WIP limits explicit is to 

write those limits in the 

column headers of your 

Kanban board, as in 

Figure 9. 

In our example, 

Development may have 

only two work items in 

progress at one time, 

whereas Validation 

may have three. Note: 

WIP limits apply to 

both work in progress 

and done items. 

Figure 9: Kanban board column headers with WIP and Queue limits embedded 

Figure 10 uses a simpler approach, one more common to Lean manufacturing. The Kanban 

board includes limits WIP with a corresponding number of slots in every column or step. 

So, someone who attempts to add a work item at the Validation stage, when all three slots are 

filled, knows that he or she should not have pulled that item from development. 

Similarly, a manager who sees work items on the board, outside of slots, knows that the 

process needs management. 

URGENT (1) 

HIGH (2) 

NORMAL (6) 

LOW (6) 

BACKLOG 

6 2 

2 3 4 4 

CUSTOMER 

ANALYSIS DEVELOPMENT VALIDATION ACCEPTANCE DELIVERY 

Figure 10: A Kanban board using simple slots for WIP. 

As we discussed in the section “Limit WIP,” these limits are subject to change. At the 

beginning of the project, they are the team’s best estimate of its capacity. It may find that it 

is capable of managing more work items, or less, or you may discover that from managing 

repeated bottlenecks.

POLICIES FOR 

PRIORITIES 

Explicit prioritization 

makes it easy for the 

team to choose WIP 

when they pull from 

upstream. Ideally, team 

members do not have to 

decide which items 

to pull. 

Think “engineering ready” versus “backlog” 

The backlog is the bushel of ideas for a project, a 

potentially infinite cache of features and functions, 

which must be prioritized and constantly groomed. 

If Gear Stream had its way, there would be no states on 

a Kanban board reading “Backlog” or “Queue.” Those 

columns would read “Engineering Ready,” and there 

would be nothing in that column that you don’t want 

the team to work on. 

The overarching goal of Kanban is to deliver the 

highest possible value to the customer in a fast, 

efficient way. The key enablers are 1) to reduce 

cycle time and 2) to increase workflow, but a third 

is selecting items that are of the highest value. 

The Product Owner typically makes that judgment, 

with input from the team, during the planning meeting. 

How to prioritize 

Due dates are the most obvious way to prioritize 

work. These are fixed dates that have been discussed 

with the customer rather than theoretical or “nice-tohave-it-by” 

dates from the customer or other 

team members. 

A second criterion for prioritization is urgency. 

There are four basic classifications: 

• Urgent for work items that require the team’s 

attention (e.g., ones that are past due date) 

• High for work items at risk of being late 

• Normal for the majority of items 

• Low for items that can be delayed without 

creating urgency 

Still another tool for prioritization is class of service, 

defined in service level agreements (SLAs). In essence, 

the team charges more for high-priority work. Its 

complexities are beyond the scope of this book, but 

here is an example: 

• Standard Class: $0, common for typical user stories 

• Priority Class: $750, typically critical bugs and 

high-priority user stories 

• Fixed-Deadline Class: $0–$2,500, user stories 

• Expedite Class: $4,000–$6,000, for example, a 

blocker bug (may require breaking WIP limits) 

The SLA defines the costs and the expected delivery. 

That delivery is based on a realistic assessment of 

historic delivery times, being a mean delivery time (e.g., 

twenty days for Standard Class user stories, four days 

for Expedite Class). 

The SLA might also account for standard deviations, 

based on the cycle time metrics we covered in Chapter 

3. You may offer the customer such delivery data as: 

• A confidence estimate, such as “85% delivered by 

mean cycle time” 

• A 90% estimate, such as “90% within 15 days 

for Standard Class,” which should be lower than 

historic delivery times 



SWIM LANES 

How is the team to 

identify the urgency 

of the items? 

A simple method is to divide the Kanban board into “swim 

lanes,” based on urgency or service class. Figure 11 shows an 

example. Each swim lane should have its own WIP. Most items 

should fall into the normal lane, but a good rule to set is that no 

more than one urgent item is allowable at any step and two 

high items (in an ideal world, of course). 

Similarly, you may choose to create swim lanes by: 

• Work type 

• Customers, with an understanding of which customer’s 

work takes priority

RELEASE 

FREQUENCY 

(CADENCE) 

As we saw earlier in the section “Measure and Manage Flow,” a consistent delivery 

cadence maximizes value in several ways. It: 

• Lowers holding costs 

• Balances transaction costs, 

making sure that transactions 

are neither too frequent or 

infrequent 

• Builds trust with the customer 

A once-a-week or biweekly delivery 

cadence suffices at most 

organizations. 

Key Policy Points: 

• Allow that policies will change 

• Explicit WIP limits ensure 

continuous flow 

• A clear definition of Engineering 

Readiness keeps superfluous 

work out of the queue 

• A clear Definition of Done 

ensures that only quality work 

is delivered 

BACKLOG 

6 2 

2 3 4 4 

CUSTOMER 

ANALYSIS DEVELOPMENT VALIDATION ACCEPTANCE DELIVERY 

URGENT (1) 

HIGH (2) 

NORMAL (6) 

LOW (6) 

Figure 11: Swim lanes make priorities visual and explicit 


6. IMPROVE 

COLLABORATIVELY 

(USING MODELS) 

Sometimes when you innovate, you make mistakes. It is best to admit them quickly, 

vvand get on with improving your other innovations 

– Steve Jobs


IMPROVE 

COLLABOR- 

ATIVELY 

(USING 

MODELS) 

Bravo! For committing 

to Kanban and changing 

your processes. But 

the change has just 

begun. Kanban is a tool 

for pushing forward 

with evolutionary, 

incremental change. 

Something the Toyota Production 

System (from which Kanban derives) 

did wonderfully well was to “democratize” 

change. It entrusted the front-line workers 

to recognize and implement opportunities 

for improvement. 

Toyota instituted Kaizen events in which 

workers in a Kaizen circle identify and make 

changes—collaboratively. Kaizen, by the way, 

loosely interprets as “good change.” These 

front-line workers do not need to check with 

management, yet management is typically 

involved. This reflects the radically different 

way that Toyota managers and leaders 

operate, something that we can’t address 

here, unfortunately. 

It instituted Kaizen events in which workers in a Kaizen 

circle recognized the need for and make changes – 

collaboratively. Those front-line workers did not need 

to check with management, as management was 

typically involved. (Kaizen, by the way, loosely 

interprets as “good change.”) 

The typical Kaizen cycle in software engineering is– 

1. Standardize an operation 

2. Measure the operation (e.g., its cumulative flow 

or cycle time) 

3. Gauge those measures against requirements 

4. Introduce improvements to increase productivity 

or meet requirements 

5. Standardize the improvements 

6. Return to step 1 

A similar model is the Plan-Do-Check-Act (PDCA) 

model conceived by productivity guru William 

Edwards Deming. To act is to take corrective actions 

when expectations aren’t met—pretty similar to Kaizen. 

Use your Kanban tools 

You have all the tools you need to begin making 

collaborative change. Let’s review them: 

1. Planning meetings 

2. Stand-up meetings 

3. Retrospective meetings 

4. The cumulative flow diagram, or CFD 

5. The cycle time diagram 

Recall the charter we outlined at the beginning of this 

book: we maximize value by improving cycle times 

and workflow. 

Thus, the subject of every planning, stand-up, or 

retrospective meeting you have in the course of a 

project are cycle time and flow. Have updated 

diagrams ready for your retrospective meetings in 

particular and rather than discussing off the cuff what 

did or didn’t go well, use these diagrams to begin your 

discussions. 



USE MODELS 

FOR CHANGE 

Anderson suggests three useful models for 

improvement, each of which creates a shared 

understanding and consensus. They are: 

• The Theory of Constraints (or TOC—bottlenecks) 

• The System of Profound Knowledge 

• The Lean Economic Model 

The Theory of Constraints you know already. 

Swarm your constraints and you facilitate flow. 

The System of Profound Knowledge was also 

conceived by W. Edwards Deming. It creates a 

culture in which knowledge is welcome, change is 

welcome, and individuals are safe to suggest and 

make improvements without fear of failure reprimand. 

Maybe that sounds “touchy-feely,” but ultimately it’s 

very practical. 

A Kanban team is self-reporting and self-correcting. 

It gathers knowledge and statistics for its own purpose, 

which is to maximize the value it produces. It does not 

fear suboptimal metrics, but rather, relishes an 

opportunity for improvement. 

This takes getting used to. Because teams are used to 

gathering data for management, they are tempted to 

misreport the results out of fear. As Deming put it, “A 

committee appointed by the President of a company 

will report what the President wishes to hear. Would 

they dare report otherwise?” 

In a System of Profound Knowledge, the team also has 

a deep knowledge of variation as it relates to process. 

Some of the variations we have touched upon: 

• Bugs and other product defects 

• Longer-than-usual cycle times 

• WIP overloads 

• Budget overruns 

• Overtime 

Variations are deviations from the expected or 

desired output—not causes. Deming observed that 

there are both common and special causes of 

variation; a product owner who allows “scope creep” 

to affect cycle time on every project is a common 

cause. A one-time request from a valued customer 

is a special cause. 

In either instance, the Kanban team’s charter is to 

acknowledge the variation, identify its cause, and 

revise the process to safeguard against that variation.

There is far more to the System of Profound 

Knowledge. Read Deming’s The New Economics: For 

Industry, Government, Education, available from MIT 

Press to learn more. 

The Lean Economic Model is similarly complex, but at 

its core is elimination of waste. By eliminating waste in 

all its forms, you create only value for the customer. 

This in turn boosts profit. 

The Toyota Production System recognizes three kinds 

of waste, each with a Japanese name: 

1. Muda—includes overprocessing, excess inventory 

(WIP), defects, and waiting, along with other forms 

of general waste 

2. Mura—unevenness, inconsistency, variation 

in workflow 

3. Muri—overburden of workers or teams, which 

in turn creates defects 

Toyota’s inventory is cars; in software engineering, 

inventory is unseen, yet it also produces concrete 

artifacts for the end user. Under TPS, Toyota would not 

produce a car for which there is no order. Similarly, in 

Kanban, a team does no work that a customer has not 

requested. 

So how do you eliminate waste? 

You’re there already! That is, if you have been actively 

using Kanban. Have you heard the term “Nature 

deplores a vacuum”? Kanban deplores waste and 

eliminates it in all its forms, including: 

• the waste of waiting by ensuring continuous flow 

• the waste of excess inventory by reacting only to 

customer requests 

• the waste of overburden with WIP limits 

• the waste of defects by eliminating such causes 

as overburdening, overpromising 

• It has tools to recognize waste (like CFD) and 

mechanisms to eliminate it (like retrospective 

meetings). 

Eliminate waste and everything left over 

will be value-adding work. 

Key Improvement Points 

• Improvements must be standardized to 

become lasting 

• A System of Profound Knowledge fosters 

transparency and self-correction 

• Eliminating constraints creates value 

• Eliminating waste leaves only value 


7 . THE NEXT 

MOVE IS YOURS


YOUR MOVE - 

If you’re looking for help 

with Kanban and Agile 

delivery improvements, 

give us a call! Gear 

Stream has a broad 

range of Lean and Agile 

transformation services 

designed to radically 

improve your innovation 

and software delivery 

pipeline. 

Our services include 

on-site workshops, 

embedded coaching, and 

the world’s only On 

Demand Agile Cloud 

Software Factory. 

We hope this eBook has given you useful insights and inspired you to move 

forward on your Agile journey and to consider using Kanban on real projects 

in your company. We would also love to get your feedback and for you to share 

stories about how it might have helped you achieve better ROI for you and 

your customers. 

Brad Murphy, Founder & CEO 

Gear Stream, Inc. 

Send Us Your Kanban 

Questions or Feedback to: 

Kanban@gearstream.com 

For More Information, 

Call or Visit Us At: 

1-800-935-1420 

www.GearStream.com

Gear_Stream-EBook_Getting_Started_w_Kanban

Create successful ePaper yourself

Delete template?

Save as template?