Visualize work: a short intro to Kanban boards


Too often I see people struggling in managing their work simply for a “big” root cause: they fail to visualize ALL the work involved. A very simple tool that can help is a Kanban board, let see what it is and how we can implement it.

A kanban board is a tool for “managing” flows in process. For example, in software development we could manage the typical flow of artifacts we produce/consume:

But don’t forget that such tool is not specific for software (indeed it was born outside software field).

Essentially we use kanban for three main aspects:

The best part of kanban (IMHO) is that introducing it is mainly “risk free”: it’s a simple tool, it scales well, it’s not difficult to understand, it doesn’t disrupt your existing process(es).

Finally, don’t underestimate the fact that a Kanban board is an effective information radiator.

So, why not?

How to set up

First, map your flow describing what happens when you work on your “artifacts” from the beginning to the end. A classic example for software production could be something like that:

backlog -> development -> test -> deploy -> done

But your mileage may vary. My suggestion is: follow simplicity.

A deck of post-it, some sharpies and an A1/A0 sheet put on a wall is sufficient. Please, do not start with software tools…

At this point you can write down your tasks (on post-its) and placing them on you board. Each task need some simple information:

Try different post-it colors if you need to differentiate between “artifacts” types:

You could also add information about “who” is working on it now: again use (smaller) post-it with the person’ name to put near the task (or funny avatars…).

Here is a nice example:

Note how simple is to know who is working on what, which artifacts need to be verified, and so on.


For each identified step establish an upper limit on how much you can do at the same time: the work in progress (WIP). Of course do that only for “working” step (eg: a “done” or “backlog” step doesn’t need a WIP…)

The key aspect to understand now is that when a task starts to be worked on it should leave the board as soon as possible.

Finding, for each step, a limited WIP help in achieving this goal. In other words WIP limit helps us to focus on finishing things rather than starting new ones. Often lowering that number improves our process throughput.

Of course breaking a WIP is not the end of the World, but be conscious on what are you doing and, more importantly, why you are breaking it. For example, fixing a blocking bug in production code has a large priority over the rest, so feel free to break the WIP limits, freeze some tasks and reallocate people (business is business…), but generally avoid that breaking becomes the norm.

Starting to see benefits

Now you can be aware, inspecting the board, when and where a bottleneck forms: it appears “near” the saturated WIP in a given column (step). For example: developers are breaking the “coding” WIP, why? Maybe testing team is overwhelmed and can’t accept more code to testing…

The simple fact that you can visualize what’s happening on your process (at any scale most appropriate for you) is an evident benefit. Questions like these can be easily answered:

Sharing knowledge

I didn’t mention nothing about procedures, rules, how many task a person can be assigned to, and so on. It’s up to you and your environment culture to handle all that, but let me give some suggestions: be simple and effective, write them by (memorable) examples near the kanban board, avoid unnecessary complexity (what takes too much time to understand is generally not applied).


Within a Kanban board you can measure a lot of things: but again - I advice you - start small and test often if what are you measuring is really useful or not (measuring has a cost).

How many “artifacts” do you ship every week? This is a classical measure of throughput of your process. Suppose you deliver “features” for a SW project, then at the end of each week/month you can measure how many of these you are able to deliver. Starting from those data you can easily build a burn-up chart (excellent short post of Nik Silver about it) showing features or work delivered over time.

Is that useful? The slope of the burn-up chart can easily tell you if are you progressing or not, and you can also easily see if and when the project scope changed.

A burn-up chart

Finally, please note that such chart has a twofold usage:

Another thing worth measuring is the “cycle time” (or flow time): how long it takes to a feature to get done. It can be simply calculated from a “start date” and “end date” fields (related to a typical “start working step” till to “finished working step”). With this we can see how effectively an artifact is worked in our process (and start asking ourselves “why” it take so long…).


After reading this post, I hope you find yourself more comfortable with a Kanban and soon start to experiment with it.

(Photo credits: Oliver Tacke, KanbanJoy, Bluesoft Brasil, Nick Silver)


blog comments powered by Disqus