In Part 1 I covered some of my takeaways from the training and basic tenets of Kanban. In Part 2 I focused entirely on the notion of process policies. In this post I want to discuss the Kanban board, one of the key artifacts of the Kanban software development process.

At first glance, a Kanban board looks just like a Task board used in most Scrum environments.

(This board was reconstructed from photos of boards used at Yahoo.)

So how is it different than a task board? The answer to this question will be the topic of the rest of this post. I will answer this question by pointing out the key differences between Kanban and Scrum

1. Time-boxes are no longer needed therefore what you see on the board is not the work for the current timebox but will stay on the board for as long as it takes to complete the story
2. Stories are at the minimum marketable feature (MMF) level. There is no value seen in breaking down stories beyond the point of an MMF since, by definition, their completion would not add any marketable value to the product. There is also no longer a need to break down the story into its tasks.
3. The “To-Do” column of the task board is replaced by all the steps in your workflow (aka value stream). A common development flow consists of
   1. Story elaboration
   2. Development
   3. Testing
   4. Deployment

Kanban explicitly tracks a story's passage through each step in the flow so that it can control the work in progress within each step and identify bottlenecks in the flow so that they can be removed.

Steps can be added or subtracted as necessary. Kanban explicitly tracks a story's passage through each step in the flow so that it can control the work in progress within each step and identify and deal with bottlenecks as they arise.  Cards can be moved back to a previous step if they need rework.

4.    Explicit work in progress (WIP) limits are set across the entire work flow written on the bottom of each step. In this example, the entire WIP limit is set at 17. That is, no more than 17 user stories can be on the card wall at any given time. In addition, each step has WIP limits. In our example, the testing step has a limit of 3 user stories. What this means is that as soon as there are 3 stories in the test area no more cards can flow through to testing. Developers will need to stop producing work for the testers but instead, ask them for ways they can ease their burden. There are best practices for setting step limits but that is beyond the scope of this post.

5.    Kanban makes provision for urgent user stories (usually production issues) that need immediate attention. These stories are “fast tracked” ahead of those currently in the system. There is no longer the “no interrupt rule”. The “Expedite” lane is where these types of user stories cross through.

6.    Instead of tracking the throughput by the number of story points accomplished (velocity), Kanban measures the cycle time of each story. This is also explained as the average wait time for a user story. In our example, from the time a user story is placed on the Story Queue it can be expected to complete in 18 days.

Even though there are no iterations, there are periodic product demos, and retrospectives as deemed necessary by the team and other stakeholders.
I really appreciate the flexibility afforded by the Kanban system with the emphasis placed on Lean concepts of optimizing for flow and limiting work in progress. In my opinion, there are many teams who will benefit greatly by adopting Kanban. This is especially true If you are leading a maintenance or sustained engineering organization.

Read the story of David Anderson at Corbis for further inspiration.
I hope you’ve enjoyed this article. I would greatly appreciate any comments.

Regards,

Armond Mehrabian
Sr. Consultant, Portofino Solutions
San Diego, CA