Kanban is designed to manage the creation of products (software usually) with an emphasis on continuous delivery. The aim is not to overwork the development team, but work in a steady manner. The way they do this is by limiting the number of tickets anyone in the team can work on at once, making the workflow steady and consistent with an even flow. Just like Scrum, Kanban helps teams work together in a collaboratively and effectively. Kanban has an easy to track method, in which you manage the workflow easily as you progress well through a series of status boards, i.e. ‘Work To Do’, ‘In Progress’ and ‘Work Done’ etc.

The Kanban characteristics make it a great fit for smaller but more frequent workflows because of its clarity and simplicity. I enjoy the process and would recommend it for anyone needing to manage small but continuous streams of work.

How it works

Kanban uses three basis principles as a framework, they are:

1. Visualise what you can do (through status boards). To do this, you simply view all of the items in the context of each other. Seeing items visually can help interpret patterns and see potential work streams naturally. This process can be very informative.
2. Reduce the amount of work in progress, enabling you to control the workflow more steadily in short iterations. This allows you the ability to control the work stream without having to commit too much at once.
3. Enhance your work stream, when an item is completed, the next highest priority from the backlog is worked on next.

What is it best used for?

In my experience it is ideal for small projects and other support initiatives, because its simplicity makes it a great fit for these types of projects. Moreover, other teams such as bug fix teams, call centres, sales and marketing (to name a few) have all embraced Kanban.

Are you in a team that uses Kanban, what are your experiences with it?

For more information, refer to The Kanban Guide for Scrum Teams.