My Kanban Technique

In software development, a kanban board is a way of putting your todo-list (backlog) on a whiteboard using one post-it per item. I have been experimenting with my own style of kanban board for some time now. Its benefits are:

• measures velocity (how quickly the development team can deliver new features)
  
• measures the impact of bugs on the development team
  
• measures the quality of planning and estimates
  
• over time, allows you to fine-tune the overhead of planning and estimating
  
• allows client to prioritize as often as they want
  
• provides detailed visibility into what developers are doing (information radiator)
• does not require fixed iterations

The above benefits are substantial, especially considering that the technique adds almost no overhead. It requires a short daily stand-up meeting of developers, in front of a whiteboard. It requires you to breakdown features into small, manageable chunks. If you already do Scrum, that adds zero daily overhead, and may well allow you to subtract some.

The technique works well for generalist-style teams of developers. (A team of 5 specialists working individually on separate parts of the application will not get the full benefits of the technique).

Moving on. Materials you will need:

• large whiteboard with colored erasable markers
  
• post-its (size 3x3 inches are ideal)
  
• sharpie or other bold pen to write on the post-its
  
• small colored stickers (at least 3 colors)

The technique is very simple, but it has multiple dimensions. I will explain it in terms of those dimensions. First dimension deals with the flow of post-its on the whiteboard.

Each post-it will represent a system feature. For planning purposes, you should aim to size the post-its to around 2 development days, i.e. it should take a single developer no more than 2-3 days to develop the feature. That said, the technique allows larger post-its (with increased risk). Simply use a different colored post-it for features that are too large (we use pink for large, and yellow for normal). You can also mark an existing post-it with a red-X to indicate it is too large.

The whiteboard will be divided into several sections. Post-its flow from left to right and never back.

The first area is the "broader backlog". For each planned customer-identified feature, place a post-it in this area. Large (pink) post-its are acceptable in this area.

Next is the "release planning area". Its purpose is to group together the features that will be in the next release of the software. In order to transition to this area, large pink post-its must be discarded and replaced with smaller post-its, as much as possible. This implies some sort of planning and estimating meeting. The technique allows for variances in post-it sizes, so do not stress estimating too much. Just break it down as much as feasible. Later on you will have a measurement of estimate quality, and can use that to motivate spending more or less time estimating and planning.

For Scrum users: There is no need for the 2-day items to be customer-focused. At this point, if your client agrees, then you can break-down into technical tasks.

For each release, count and record (on the whiteboard) the initial number of post-its. We will call this the "size of the release". Later, once we have measured velocity, we will be able to simply divide the size by the weekly velocity to reach the estimated weeks until release.

Next area of the whiteboard is the "current backlog". This is a prioritized area where higher priority items are towards the top, and lower priority items towards the bottom. The area is limited in that there is only space for 7 items. (7 is a good starting number - you can tweak the number later). The area represents a "turnaround guarantee" to the client. We will say that the client can put anything (sized appropriately) at the top of this area, at any time, and we will have it done within X days. The X days is calculated based on the team's velocity. For example, if the teams velocity is 1 post-it per day, then we will completely empty the current backlog (max 7 items) in 7 days. Based on this, we can guarantee (not 100%, but close) a turnaround time of 7 days.

When I said "the client can put anything" in the current backlog, I really mean *anything*. The item can be a bug, a new unforeseen feature, or whatever. It does not matter. They write it on a post-it, and put it in the current backlog.

Developers pull items from the current backlog, usually from the top (high priority) down. If possible, they should avoid pulling more than one item at a time.

Next whiteboard area is the "developer assignment area". Each developer has a small box with their initials. When they pull an item from the backlog, they place it in their box.

Next area is the "impediment area". When a developer cannot proceed on an item (waiting on purchase of 3rd party component for example) then they move it out of their box into the impediment area. Next to the impediment, they write the reason. While impeded, the developer stops working on the item. They can pull another item from the backlog. Impeded items are escalated as needed. Once they become unimpeded, they are moved directly back to the developer that was working on them.

When done with an item, the developer can move it to a "done" area. This is drawn like a weekly calendar, and the developer simply places the done item on the day on which it was completed. Done items stack up beneath each day (and provide a surprising sense of accomplishment).

If you have additional steps between the developer saying they are done and acceptance of "doneness", you can add those as areas in the whiteboard. The following is important though:

• If an item needs to go backwards (from tester to developer for example), then the post-it should not move backward - rather create a new post-it and leave the existing one where it is. (This is important to our effort to quantify the effect of poor quality).
  
• Someone must be responsible for removing items from every area. For example, if no-one is actually doing work on assuring quality then do not invent a quality area.
  

And that is how the post-its flow. Pretty simple, but by itself, it does not give you much.

The next dimension is the colored stickers. Each post-it is decorated with stickers, in the following way:

• blue - bugs. When an item has been assumed to be done (placed in the "done" area), but a bug is discovered, then a new post-it is added to the current backlog with a blue sticker (don't move the "done" post-it back).
• green - missed requirements, or post-its that are "broken out" from larger features during development. Green items can sometimes represent just-in-time work-breakdowns. For example, a developer can take an existing post-it in his area, break off another post-it (with a green sticker) and place it in the current backlog.
  
• red (optional) - for each day that a developer works on a post-it, it is decorated with a red post-it. Too many red post-its is often an indication of a problem that needs to be escalated.
  

The final dimension is the measurements. There are 3 measurements, taken weekly (first thing on Monday works for me). The measurements are all performed by counting post-its in the "done" area. Once counted, the post-its are removed from the white-board. They are:

• Velocity. Count each post-it, except for those with blue or green stickers. Higher is better.
  
• Estimate Quality. Count each post-it with a green sticker. Higher is worse.
  
• Product Quality. Count each post-it with a blue sticker. Higher is worse.

And that's it, in a nutshell.

Velocity is measured relative to the release planning area, which is the only way that is meaningful to a client. Use velocity directly to plan releases and choose a max size for the current backlog area.

Estimate quality is a measure of the risk of using your velocity for planning purposes. Each point was an unknown at release planning time. We did build the risk into the velocity, but a high enough value is...risky. If that is a concern, then you need to spend more effort planning and estimating.

Product Quality is a measure of how bugs are affecting your ability to implement new features. A high value means that you should put more effort into improving quality before saying something is done. This is almost always a good investment.