Elements and Rules of KANBAN Project Management

KANBAN boards are great. They are comprised of two components only: lists and cards. To get started with a KANBAN board, just name some lists, add some items on cards and move the cards between these lists. That’s it. KANBAN boards help you to order your items and to keep the overview of whatever status you want to observe.

However, using a KANBAN board in a project does not turn the project into an agile KANBAN project. The KANBAN project management methodology actually requires much more.

Buy-in into AGILE principles

First and foremost it requires buy-in into the AGILE principles. The KANBAN project management methodology has been designed to achieve:

• high customer satisfaction through an extreme customer focus, with agile reactions towards changed customer requirements or altering circumstances,

• adaptable, efficient, fast and high-quality implementations in complex environments trough product ownership and self-managing teams which are review and feedback driven.

People, teams and resources

Second, KANBAN project management requires context like every other project: SMART objectives, resources, expense budgets, dedicated support, software, infrastructure, knowledge and experience. People are the most valuable driver to successful KANBAN projects:

• A project has a dedicated team with truly assigned, dedicated and motivated team members.

• One team member will have the role of the product owner. Another team member will have the role of a KANBAN master.

• All people in the project or the context of the project who contribute one way or another are named with their roles and responsibilities within the project and put on the project people list.

KANBAN board management and status reporting

Third, the KANBAN project management methodologies demands 100% transparency on information, clear communication and visible measures of progress.

For managing the KANBAN boards here are the elements and rules:

• Each KANBAN boards starts with a BACKLOG list and ends with a COMPLETED list.

• Between the BACKLOG and COMPLETED lists can be an arbitrary amount of lists with arbitrary names.

• Each of these list has to two columns: WIP — Work In Progress and DONE.

• DONE is defined by the team. The number of cards in a list other than BACKLOG or COMPLETED must respect the WIP limit.

• New cards can only be created in the BACKLOG list.

• Each card must have a unique identifier to track its progress.

• Cards are pulled into the next column by their owner.

• Ownership is typically self-assigned by a team member (because the team is self-managing). Previous ownership ends when a new owner is taking over. Takeover takes place in DONE columns. Ownership is tracked, but the last owner is the current owner.

• Each card that is neither in BACKLOG or COMPLETED must have a unique owner.

• No card can enter a column if the WIP limit is already reached. Exceptions are granted for cards that move on the fast line. The fast lane goes across all columns to allow for very high priority cards that must be dealt with immediately for superordinate reasons and, therefore cannot wait in the queue.

• Deleted cards will be moved to the WASTEBIN.

• Progress is tracked (ideally) every day by moving cards. The moving of cards should take place in a short team meeting (often called Daily Sync or similar).

• Time points when cards enter or leave WIP or DONE columns are tracked.

• Cards enter DONE columns based on team agreed DONE criteria.

• The quality of a card in a DONE column should be reviewed either by the new owner or by another team member. Cards that fulfil the criteria will have quality green. When they move on into the next WIP column they go back to the neutral color (e.g. blue). Cards that do not fulfil the criteria receive a red color for poor quality. They need to go back to the previous WIP column but keep their red color.

In addition, a KANBAN project control report needs to be produced that measures:

• time to completion (a.k.a. lead time), i.e. from BACKLOG to COMPLETED per card and as distribution

• time in WIP per card and as distribution

• time in DONE per card and as distribution

• number of WIPs / day

• number of DONEs / day

• number of quality issues and declines / day

• value added time per member and per team

• punctuality towards customer

• customer satisfaction

• team satisfaction

On that basis, forecasts should be given to the customer, by when the next iteration or feature set will be completed or by when a new product version will be reached. The accuracy of these forecasts should also be measured in order to achieve high punctuality towards the customer.

Further application and summary

By adding further lists, such as a SPRINT BACKLOG, a KANBAN board and its project methodology can easily be extended to serve also a SCRUM project.

If all the above measures are properly implemented the KANBAN project methodology will most likely be successful and will probably reach a high customer as well as team satisfaction. And that is exactly what it was devised for.