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
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
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
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
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