Designing a Kanban Board – Not as Simple as you Might Think

A Kanban board is not necessarily the most complicated thing under the sun, but if you've thought that it's impossible to fail at creating a good one, you may have been wrong. Here is a great example of what not to do.

The workload situation is: a nice backlog of product maintenance items (small bug fixes and minor change requests). As there was no specific deadlines, the team leader decided on trying out a Kanban board.

These are the process stages that he and the team have come up with:

1. 1. A backlog of stories
2. 2. A pre-plan (here a developer with product owner and QA engineer decided on what exactly needed to be done)
3. 3. Ready for development column (from which any free developer could pull)
4. 4. Development tasks (broken down into work items)
5. 5. In process of development - once the whole task was done, the developer needed to consult a QA engineer before sliding it further
6. 6. Ready for tests (from here a QA engineer pulled his tasks)
7. 7. Done - once all tests are passed, the task was considered completed

While the team was sure, that this board actually represents the way they worked, once implemented it quickly turned out that more often than not cards were just skipping particular stages (ready for development, development tasks and ready for tests). So all quality consultation and work items division activity was omitted.

The reasons for this were, that once the task has been discussed, the developer wasn't going to place it in a column for someone else to pick up, he just got on and begun working on to straight away (column 2 redundant). Because the tasks that the team was dealing with were mainly small bug fixes, there was no need to split them into smaller items, therefore no need for column 3 at all. Once the developed item had been showed to a QA engineer, he normally just got on with tests, it almost never happened that the task needed to wait for testing to begin (no need for column 5).

All these changes had been discovered during a retrospective meeting and the board has evolved since there even more. The point here is that no matter how well you think you know the workflow, this doesn't necessarily mean that you do. It's always beneficial to stop, think and observe.

Read our article on Online Kanban board »