Kanban comes from lean production and literally means “sign board”. The original purpose of a kanban was to notify people in a manufacturing process when more supplies/materials were needed. The goal was to minimize waste in the production process, such as making too many parts, storing inventory, or waiting for new inventory to be created.

Non-manufacturing processes also benefit from kanban boards. In fact, any corporate project or initiative can be organized via kanban. Kanbans are great because they

• provide a central location for all work associated with an initiative, which
• centralize progress and status updates related to the initiative;
• help identify where resources are needed at any point in time;
• help estimate the duration of a project;
• help identify tasks that are too complex and need to be divided into smaller tasks;
• visually identify where in a process a bottleneck exists; and
• visually identify people that are overallocated or spread too thinly.

Structure

Kanban models a workflow or process using a sequence of columns. Each column in a kanban represents a stage or step in the workflow. Cards represent a unit of work that flows through the process. As a card moves through the process, different people work on it until it reaches the end of the process.

At Pez, we define the following stages (columns) in our development process:

• Ideas - unprioritized work. Anyone can add a card to Ideas
• Backlog - Prioritized work that have been properly defined. Only a project manager/leader can move cards from the Ideas to Backlog
• In Progress - Cards actively being worked on
• Blocked - Cards stuck waiting for external input or dependent on completion of another card
• For Review - Cards ready for external review
• Done - Completed cards

You can define any set of columns you want. Generally you want to have at least one column for things to do (backlog), one for things being worked on (in progress), and things completed (done). Try to balance simplicity with sufficient granularity. If you try to capture every stage of a process in a kanban, it will become too cumbersome to be effective.

What’s special about kanban is that it focuses on the work to be done as opposed to the people doing it. Traditional project management approaches start with “resources” and then assign tasks to each resource. There is a lot of overhead with this approach and plans must be tweaked regularly to account for project delays and other contingencies.

With kanban (and other agile approaches) the focus is on a user story, or what we call an atomic unit of delivery (AUD). Each column represents a queue of work to be done. Workers are assigned specific queues and keep working through the items. With this approach, it’s easier for people to self-organize since they can choose any appropriate work in the queue. It also makes people fungible in a good way: if someone gets delayed, someone else on the team can still work on other AUDs that are in the backlog. Thinking in terms of atomic units of work also helps remove interdependencies that can pathologically extend the critical path.

Rules and Process

Kanban only works if everyone is disciplined about following the process. If the process is followed inconsistently, this leads to miscommunication, which leads to wasted time and effort. The rules and process must be 1) clear, so it’s easy to follow, and 2) simple, so it minimizes overhead.

Since kanban is describing a process, it’s helpful to think of how cards move from one column to another and who is allowed to move them.

We use Trello for our kanban. The following rules use terminology that may be specific to Trello, but for the most part will work in any project management tool that supports a kanban structure.

Ideas

Whenever someone has an idea for an improvement, bug fix, feature, a card can be added to Ideas. At a minimum, a card in Ideas needs to have:

• A title in user story (short) form: I want to <action>

Ideally, the card should have more information, and it pays to spend 5-10 minutes adding detail. If you wait, you’ll find it’s harder to remember the rationale for some work, which wastes time. So try to include:

• The complete user story: As <actor>, I want to <action>, so that I can <goal>
• Background: how does this user story tie into the bigger picture?
• Impact: how does the user story benefit customers, the company, or the employees?
• Urgency: why does this need to happen now? what is the consequence if it isn’t worked on right now?

AUDs attempt to balance the simplicity of user stories with the technical detail of use cases. The minimum required to enter Ideas is the user story, while to enter the backlog, the AUD needs to be more like a use case. Here are some tips for writing use cases.

Backlog

The backlog represents work that has been agreed to be worked on. Generally, a project or product manager moves cards from Ideas to the Backlog. To be in the Backlog, an AUD must have everything described in Ideas as well as a

• Time estimate: A rough estimate of the amount of actual work required, not including meetings, etc. The point isn’t to be exact but to help identify differing expectations regarding the difficulty or amount of work to be done. We use special labels 1h, 2h, 4h, 1d, 2d. Anything greater than two days embodies too much complexity and needs to be divided into smaller AUDs. If not, the time estimate is too unreliable and therefore useless
• Release label or tag: the release or phase of an initiative it is part of. Work can be grouped into phases or releases. A sprint planning session can be used to debate priorities and define releases. I will discuss sprint planning and releases in a separate post.

When the backlog queue is near empty, it’s time to fill it back up. This can either happen during a sprint planning meeting, or a product manager or other team of stakeholders can work together to fill in details of cards in Ideas and move them to the Backlog.

In Progress

When an individual contributor begins working on a card, she moves the card from the Backlog to In Progress. This person becomes the card owner and is responsible for adding some information to the card:

• Owner: who is responsible for ensuring this work is completed? A card must have exactly one owner, though multiple people can work on it. If there are multiple owners, it creates waste through increased coordination and usually results in a lot of miscommunication
• Due date: when is the card expected to be completed? If someone is only allocated on a single card, the due date should be the current date plus the time estimate. If not, there should be a reason why not

If there are too many cards In Progress, that usually indicates a problem. Similarly, if no cards are In Progress, that can signal a bottleneck elsewhere in the process. These are wastes that can be remedied.

Blocked

When progress on a card is impeded by something outside of the owner’s control, the owner moves a card from In Progress to Blocked. Some scenarios that lead to a blocked card include:

• when a card depends on another card and that card is not done
• when a card depends on external input (e.g. needs more details in requirements)

In all these cases, the owner is WAITING. It’s therefore important to get the card out of Blocked, since any INVENTORY in that list produces waste.

Note that if a card has been deprioritized in favor of some other card, this card should be moved back to the Backlog and not to Blocked. Remember, if a card is in the Backlog, anyone can work on it. So if someone else has spare capacity, the card can get a new owner. That won’t happen if it gets stuck in Blocked.

One of the pitfalls of a Blocked column is that people often don’t know who is responsible for unblocking the card. My general rule is that the card owner must

1. indicate why a card is blocked
2. update the Due Date for when they think the card will be unblocked
3. follow up with owner of blocking card to ensure there are no new delays
4. if additional delays occur, escalate to product manager

For Review

When an AUD is ready for approval or external review, the owner moves the card from In Progress to Review. The type of review depends on the type of initiative:

• software - design review, code review
• marketing, sales - copy review
• HR - policy review

Whenever a card appears in Review, a designated reviewer begins the review process. Reviews depend on the type of initiative. Software reviews ensure

• requirements are clear,
• the work satisfies the requirements,
• unsupported edge cases are documented, and
• tests have sufficient coverage.

Any issues identified by the reviewer are logged in the card comments. Ideally, the owner and reviewer agree on whether the card requires additional work or not. If there is disagreement, a third party (manager or peer) should break the impasse.

If additional work is required, the owner should move the card back to In Progress.

It is up to the card owner to ensure the review happens quickly. This avoids coordination MOVEMENT that can lead to things slipping through cracks. That said, owners need to have expectation that they see a card through to the Done state.

Done

If an AUD passes the review it is moved to Done (or to another board) by the card owner.

Cards may skip the Done state if they move to another board. This is common if a separate board exists for deployment. In this case, cards ready for deployment will skip Done and instead move to a backlog for deployment to a UAT or production environment.

Summary

Kanban is a simple, yet effective coordination approach. It works for any project with multiple people and roles. With kanban, you can eliminate waste to accomplish goals faster and improve morale.

Share your stories using kanban in the comments below.