Kanban Board Example

An example of kanban board


A team trying to cope withvery long lead times and disappointed customers.

  1. Team gets a feature request from a user
  2. Project manager schedules features for the next release
  3. Team builds the feature
  4. Team tests the feature
  5. Project manager verifies that the tests pass
  6. The feature is done and included in the next release

the Figure bellow shows what the project manager’s “happy path” version of the work‐ flow looks like on a kanban board.



This is how everyone thinks the project works

But that’s not what’s happening in real life.The team used Five Whys to learn more about their workflow. Afterward, it looked more like this:

  1. Team gets a feature request from a user
  2. Project manager schedules features for the next three-month release
  3. Team builds the feature
  4. Team tests the feature
  5. Project manager verifies that the tests pass
  6. Project manager schedules a demo with senior management
  7. If senior management wants the team to make changes to the feature, the project manager does an impact analysis on the changes, and the feature moves back to step if not, it moves on to step 8
  8. The feature is done and included in the next release


Now we know that there’s an extra step, where senior managers can optionally make changes to features and bump them to future releases after the team thought they were done.
We’ll modify the kanban board to represent this better understanding by adding a column called “Manager Review” for those features that are waiting for the demo with the senior manager.


This kanban board gives a realistic picture of how the project is run.

Now we have a more accurate visualization of the team’s workflow. If we keep the kanban board going over the course of a release, it becomes very obvious where the problem is. The work items pile up in the “Manager Review” column, and keep piling up until the end of the release, as shown in Figure bellow.


Kanban board

When you use a kanban board to visualize the workflow, problems caused by unevenness become easier to spot.

But what about the work items that were bumped to a future release to make room for the managers’ changes?

We especially care about those work items, because they’re the ones that were causing some users to switch to the competitors. Some times work for those work items has already started, and needs to keep going even when they’re bumped. When work items are bumped after the manager review, they end up going right back to the beginning of the process.



Let’s make sure these are represented on the kanban board we’ll add a column at the beginning of the board called “Bumped by Managers” and move those stickies back there (we put a small dot on each of the bumped stickies to make them easier to spot as they flow across the board a second time).


Kanban board

The kanban board makes the waste more obvious when you can see stickies go through the workflow more than once.

This is a pretty good visualization of the process that this team is following. Now we can see exactly what’s gone wrong with this project, and why the lead time keeps get ting worse.

Some people on the team probably had a pretty good idea that this was going on, but now it’s made clear to anyone who looks at the board.

And more importantly, it becomes objective and explicit evidence that the way the senior managers review the features is a major cause of the lead time problem.

Source Content = Learning Agile: Understanding Scrum, XP, Lean, and Kanban