Your Detailed Introductory Guide to the Kanban Board

What Is Kanban, and Where Did It Come From?

Like many other aspects of software engineering and agile software development, Kanban is a concept that has its roots in the lean manufacturing movement of 1950s Japan. The actual definition of Kanban from the Oxford dictionary is “a Japanese manufacturing system in which the supply of components is regulated through the use of an instruction card sent along the production line.”

Kanban was a means of eliminating waste in the lean manufacturing movement. The intent of the system was to limit the number of items manufactured to only what was strictly necessary (just-in-time production). Kanban serves a similar purpose in the world of software development.

As it pertains to software development, Kanban is a means for doing a few things:

• Organizing your work

• Visualizing your work

• Improving the process by which work gets done

In order to understand how Kanban helps us with these things, we need to learn a few key Kanban principles.

Kanban Principles

Here are some key Kanban principles that will inform how we adopt and use Kanban:

• Limit works-in-progress (WIP).

• Don’t push, pull!

• Do the most important thing first.

• Break work down into small pieces.

Let’s take a look at each of these in a little more detail.

Limit Works-in-Progress (WIP)

Kanban is designed to help you focus on doing a piece of work until it’s done before pulling the next piece of work in. The easiest way to get work done is to only work on a limited set of things until they’re complete before working on anything else. Limiting WIP helps us avoid context switching. Context switching refers to the overhead of maintaining the necessary information to switch tasks effectively, even if those tasks require a different set of skills or knowledge. Context switching is generally believed to not only reduce overall throughput but to reduce quality as well.

Don’t Push, Pull!

Kanban is predicated off of work flowing through a series of clearly defined states. The simplest states in the prototypical Kanban board are ready, doing, and done. The simplest Kanban board looks like a glorified to-do list. The difference is in the way work flows through that system. A to-do list does not have a way to represent states of various tasks, and any task could be partially done at any given time. Kanban’s pull-based system is more easily understood after understanding works-in-progress.

Imagine that our simplest Kanban board has a WIP limit of two in the doing column. What that means is that as soon as there are no longer two things in the doing column, we pull an additional item of work in. We’re always working on two and only two things. The intent is to keep work flowing through the system.

Do the Most Important Thing First

If you’ve never heard the term “backlog,” it’s a list of all the work that a software team needs to do: features, technical work, experiments to run, etc. The backlog in Kanban can be thought of as work that is either in the ready column or work that will eventually be in the ready column.

The benefit we get from doing Kanban is that we’re doing everything on a just-in-time basis. We make sure the team has enough work so that they aren’t sitting idle. However, we don’t plan too much work in advance. This allows us to be flexible with our product owner and stakeholders. They can make prioritization decisions on an almost immediate basis and can easily adapt to changing needs.

By committing to working on the most important work and only doing what is necessary at the time, we can eliminate waste. Maybe we learn that our users aren’t really thrilled with a particular feature, so we prioritize a different feature rather than continuing to layer onto an undesirable one.

Break Work Down Into Small Pieces

Many of the benefits we get by following the previous principles are rendered useless if everything we work on is large or varying in size. The flow-based system of Kanban works best when all of the work is roughly the same size and the work is small. There are several benefits to doing small chunks of work:

• Small pieces of work can be verified independently and faster.

• We reduce the feedback loop on whether the work was useful.

• We can limit the context required for any piece of work, increasing the speed at which it can be finished.

• Small, similarly sized work can help us establish a baseline on how our system works so we can more easily identify blocks and bottlenecks.

Now that we’ve taken a look at some Kanban principles, we’re ready to follow an example Kanban board evolution starting with the simplest board.

The Simplest Kanban Board

So you’re a product manager, and you believe that the current way your team is working could be improved. You’ve heard about Kanban and think that it might work well with your team. Your team includes two engineers and you. Let’s start small. The first thing you do is create three lanes. If everyone is colocated, I’d recommend using painter’s tape and index cards for this. Otherwise, there are several tools out there that can produce a digital Kanban board. I find that a physical board resonates with people and helps with the “visualizing your work” aspect, especially if the board is large and prominently displayed in the team space.

WIP Limit
2

READYDOINGDONE

Because you have two engineers, you decide to set your WIP limit to two in the doing column. This seems reasonable because it will encourage your engineers to work on a story to completion before picking up the next one.

Adding Lanes

You go through your first week of Kanban this way and then have a retrospective to figure out how you can improve your process at the end of the week. It turns out that there is some confusion about when work is done or even what “done” means. The team decides that done means that the story is deployed into production. However, you have an acceptance testing environment and a demo environment. So, you decide to add two more columns: accept and demo. Similarly, to be more descriptive, you change your final column to production. Your Kanban board now looks like this:

WIP Limit
2

READYDOINGACCEPTDEMOPRODUCTION

Now you have two more lanes for work to slide into. However, you still have the same amount of people on the team. I’ve seen occasions where each column has its own WIP limit, but in this scenario, it allows for the possibility that work sits unattended while other work builds up. My recommendation here would be to keep a WIP limit of two from the doing column through production. This WIP limit will also help prevent your engineers from losing context on work that might get rejected later in the process. If they leave something in accept or demo to pick up a new story and the work they did initially gets rejected, they’re now going to have to drop what they’re doing to resolve the original work.

Defining Done: Adding Exit Criteria to Your Columns

You go through another week with the new lanes on your Kanban board. The work seems to more accurately represent reality now that the other two columns exist. However, during the week, you get some feedback that you’ve deployed a bug into production, so during the retrospective this week, you discuss it.

The bug was a preventable one, not some nuanced complicated thing. And the engineers say that in an attempt to get some functionality out faster, they didn’t write any unit tests but had intended to fill them in after the crunch to get that feature out. The team doesn’t want to take the risk of more bugs at the expense of quality, so we decide that we’re going to add a definition of done to the doing column. We say that in order for a story to exit the doing column, any new code added must meet an 85% threshold of test coverage. This definition of done for the doing column can also be referred to as one of the doing column’s exit criteria.

Subsequently, during that retro, you point out that you didn’t get a chance to review the story containing the bug before it made it to production. You might suggest that it makes sense to add exit criteria to the accept stage. The exit criteria the team agrees on is that before a story can move to the demo environment, you as the product manager have to sign off on it in the user acceptance testing environment.

WIP Limit
2

READYDOINGACCEPTDEMOPRODUCTIONExit Criteria
85% test coveragePM approval

The board is now accurately reflecting the state of work and provides guardrails in the form of exit criteria for your work to flow through the system. However, what do we do when we’re blocked?

Oh, No! We’re Blocked!

The next week, the engineers are writing tests for their stories, and you’re accepting them in the accept stage. Things are going really well! However, your next highest priority story depends on an external team. One of your engineers finishes her current story and pulls the story with the dependency. While working on the story, she comes up to you and tells you that she has done what she can, but there’s a piece of the story she can’t complete until the other team finishes their end. What do you do?

Representing and Resolving Blocks

There are two approaches to this. The first approach is to allow blocked stories to contribute to WIP. This means that your engineer is going to be waiting on the other team to finish their work before pulling another story. I would advocate taking this approach. It forces the dependency into the open. By preventing the pulling of another story, it forces everyone involved to work on resolving the block as quickly as possible.

Sometimes this is just a conversation with another team or a sign-off from management. Regardless of whether it’s a quick fix or a longer issue, allowing it to take up a WIP slot is a surefire way to get it resolved faster. It also has the added benefit of building in slack time for additional work that may not be captured in stories. This could give the engineers time to do some refactoring or complete other nonstory tasks.

The second approach to dealing with blocks is to create a blocked section in the column where the block occurred. This approach is a bit easier to swallow for folks newer to the Kanban system. This section wouldn’t affect the WIP limit of the column it resides in. However, we absolutely want to add a WIP limit to the blocked section. This is a less extreme approach than the first one, but that doesn’t mean we can avoid all discipline when it comes to resolving blocks.

Assuming we choose the second method, our board now looks like this:

WIP Limit
2

READYDOINGACCEPTDEMOPRODUCTIONExit Criteria
85% test coverage PM approval

Blocks
BLOCKED (WIP 1)

So now we have a method for dealing with blocks. Another key point to discuss is measuring story time. Undoubtedly measurements are a controversial topic, but let’s try to tackle it together.

Tracking Story Time: Measurements With a Purpose

We’ve added a blocked section to indicate when we need help. Now the product owner is asking us if it’s possible to get a certain feature in by a certain date. We give the product owner our best guess but realize that we have the tools at our disposal to give a better answer. So at our next retrospective, we say that we’d like to begin adding a start and an end date on the stories. The intent of this is not to get the team to move faster, but to both understand the work and diagnose issues.

Once we measure story time for a few weeks, we should have gathered enough data to more confidently estimate our work. Aside from that, measuring allows us to draw data-driven conclusions about our work. For example, we can surmise that certain stories are too big or small, which helps us improve our story creation process. We can also use it to see other bottlenecks, such as if stories are waiting a long time to be accepted.

A Mandatory Disclaimer About Measuring

Ultimately, we want data points for how we can improve. Measurements should reflect what we want to learn. As with anything else, tracking story time should be done deliberately and for a purpose. Don’t measure for the sake of measuring. On one of my old teams, we added a small magnet to a story for each day it was in progress. Lots of magnets usually meant someone needed help or that there was a block. Be careful not to drown yourself in the process or demoralize the team by focusing too much on velocity measurements.

Our board seems to be approaching a state where it reflects the work and is now helping us do it even better. That’s the goal, to create a system that eliminates waste and helps us improve.

Continuing to Improve the Board

There are a number of things we can do to improve our Kanban board. There are a few guidelines I would suggest while tinkering with the Kanban board.

1. Get the team on board with changes; don’t make unilateral changes. Encourage the team to be thoughtful about the way they do work.

2. Use experiments to test changes. The changes you make don’t have to be and probably shouldn’t be de facto permanent. Say we’ll try these exit criteria for two weeks, see if it helps us, and make the decision to keep the change or revert it.

3. Don’t make too many changes at once.

4. Follow your own rules. If you set a WIP limit of two, the whole team needs to be accountable to that WIP limit. The system is only as useful as your commitment to it.

Kanban is a great tool to help visualize the state work is in and provide some rigor around the work that your team does. Not only is visualization important at the team level, but it’s also important across your whole organization. Did you know that Plutora can help you with that with its value stream management platform? Check it out! 

The starting point I detailed in this article makes sense for a small team, but what I hoped to show was that it’s not only possible but ideal to make small incremental changes to your board. Notice that we didn’t add exit criteria to every column. That’s OK! If you’re just starting, try to get your board to reflect your current process before you start experimenting. You don’t need to boil the ocean. Get everyone excited about continuous improvement. Improve continuously, keep your work small, limit your work in progress, and visualize your work. That’s Kanban!