What Is Kanban? Comprehensive Guide (2023)

Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

This framework is highly productive and effective to run.

• Ad-hoc Requests,
• Unplanned works,
• Production Support

It’s a Method of Visualizing the flow of work. in order to balance demand with available capacity and spot bottlenecks.

Quick History:

In the late 1940s, Toyota found a better engineering process from an unlikely source: the supermarket. They noticed that store clerks restocked a grocery item by their store’s inventory, not their vendor’s supply.

Only when an item was near sellout did the clerks order more. The grocers’ “just-in-time” delivery process sparked Toyota engineers to rethink their methods and pioneer a new approach—a Kanban system—that would match the inventory with demand and achieve higher levels of quality and throughput.

Kanban also spelled kanban, is a Japanese term for “signboard” or “Billboard” that indicates “available capacity (to work)”. Kanban is a concept related to lean and just-in-time (JIT) production, where it is used as a scheduling system that tells you what to produce when to produce it, and how much to pr

Kanban became an effective tool to support running a production system as a whole, and an excellent way to promote improvement. Problem areas are highlighted by reducing the number of kanban in circulation.

We will learn details about all these and how we can implement these principles, and their benefits, later in this course. You can also watch video tutorials to get a deep dive.

Principles:

Implementing software increment on Kanban Method is a pull-based system, that helps the team to continue the delivery in a sustainable pace, within capacity. It reduces the waste of effort and time. To Maintain this, it needs to follow the basic principles of Kanban as below.

1. Visualize Work:

Visual model of Kanban Board of work and its workflow to make the scope and capacity transparent, it helps to observe and inspect the flow of work moving from backlog to do. This makes the work visible—along with blockers, bottlenecks and queues, and upcoming work, which helps the team to make the strategy of working on exiting work or bringing new work in progress.

2.  Limit Work In Progress:

The Team mutually defines a Limit for all “work in progress” Columns in Kanban Board, such as Analysis, Development, Testing, etc.  This WIP limit implements the Pull based system, as work can be pulled to the current column from the previous column only if the total number of workers under the column is less than its limit. This helps balance the flow-based approach so teams don’t start and commit to too much work at once. It reduces waste and helps the team to focus on finishing first and starting later.

3. Focus On the Flow Of Work:

To Complete a work, and add value it has to pass through multiple stages of its development phase. Like Analysis, Development, Testing, Review, etc.

To get the effective benefit of Kanban the Team needs to focus on the flow of work from its initiation to completion. Following the above 2 principles helps achieve focus on flow. Focus on the workflow leads the team to visualize upcoming bottlenecks to act on. so that the flow remains. The team frequently makes a strategy of working on in-progress work items to optimize the flow.

Relate Kanban with Real life:

We already learn the basics of Kanban and its principle, let’s try to relate the Kanban flow to Real life. Assuming you already know and practice scrum, where we do Iterations of the defined timebox. we commit a bundle of stories, work on them for 2 to 3 weeks and complete the Iteration and again plan for a new bunch of stories for the next iteration. In Kanban, we don’t commit stories for iteration or time box, or sprint. we do it a little differently.

In the example below, we will relate Scum and Kanban to real life. Let’s assume the people are the stories of a movie Theater is an Iteration, show time is an iteration

This Scenario explains the flow of people in a movie Theater a bunch of people at once. If we assume the people are user stories and Showtime is an Iteration or time box. Then you may be able to notice that the group of people peoples is going to a Movie theater together and coming out together. We have a defined seat capacity and showtime. The people planned for each show is pre-planned before the show starts.

This Scenario explains the flow of people in a Public Park one by one permitted by the gatekeeper. If we assume the people are user stories, The Park is the Kanban Board. Then you may be able to notice there is no defined showtime of the park, as it is open 24 hours. The people going in or Roaming inside the park and coming out are not in a group. We don’t have the capacity or showtime. However, the management of the park decided not to allow more than 6 people at a time inside the park, to improve the comfort of the people inside.

In this picture, let’s try to relate the scenario to Scrum terminology.  If we assume the people are User stories, Then the people waiting outside the Hall for future shows are lists of User stories in the Backlog. The Active Move Theater show is the Active Sprint or Iteration. The People watching the Show Are the Stories of the active sprint. The Showtime is the Sprint Duration. The Seat capacity is the Teams capacity for the sprint. The People who already watched the movie are the “done” stories from the previous sprints, those may have been identified as released or already deployed.

And here let’s try to map Kanban terminology with the above picture. Assuming People are the User stories or Tasks, The Park is the Visual Kanban Board. People Waiting outside in a queue are active Kanban backlog. Showtime is not defined, and Max Capacity is unlimited, however, Management has decided not to allow more than 6 stories on the board.  People already moved out from the park are eating completed user stories ready to deploy. The management is taking account of stories coming out, to allow many stories to deploy. No defined start or end date for the stories/people inside the Kanban board/park.

Summarizing the above two pictures and explanation in one picture, that explains the Scrum Flow.

Summarizing the above two pictures and explanation in one picture, that explains the Kanban Flow.

Kanban Board:

Now Let’s jump into the play. We got a fair idea of Kanban and its rules, and principles. Let’s start talking about how do we really implement that principle of Visualization of flow, Implement the WIP limits, etc. You can definitely watch the video to get an understanding. I will try to explain it here also.

Well, so to make the work visible and transparent to all, we need to have a board of works, it can be physical (better for the co-located team). However nowadays most teams are situated in distributed locations, So we can have a digital board. You can use your ALM tool to configure a board like that.

Later in this section, you can browse through videos on different ALM tools like Jira, Rally, TFS, etc to find out how Kanban can be configured and implemented within those ALMs.

A Kanban Board Typically Has Three Main Sections:

1. Todo (or the Backlog)
2. In Progress (The Work in Progress Area)
3. Done (The Stories are completed.

Implementing Multiple WIP Columns:

However, to make the distribution of work, we normally distribute the In Progress work into multiple columns. For Example, we can have Analysis, Development, Testing, etc. In the picture on the right, we have distributed the In Progress work into two sections, Development and Testing.

You can make the distribution as per your need and the team’s comfort to have better control. This Distribution to more than one column always helps implement the WIP Limit for a different skill set.

Implementing WIP Limits

Limiting the count of Stories for the Work in Progress Column is one of the core principles of Kanban. By implementing the WIP Limit, you will enforce the team to focus on the flow of stories from Left to right. In this example, we have limited the number of max stories in Development to 4, and the max stories for testing are 3.

That means the team can work on max of 4 stories under the development column and max of three stories under the testing column. This Limitation will help the team to focus on finishing the stories first and then think about new stories to in progress.

For the image on right, we can see there are already 4 stories in development with a limit of 4 and 3 stories under testing with a limit of 3. So, in this case, even if the developer completes the development of 1 or more stories, they cannot pick new stories from Backlog, as there is no room for new stories or tasks under development.

To make room in the development column testers need to pull one or more stories or tasks from Dev to testing. and the Tester can only do that if they complete the testing of some existing story/task and move it to a done state. In this scenario, the Developer will not seat Ideal. They will contribute their efforts to tester and expedite the testing so the team can pull stories from development, and the developer can bring in new stories from Backlog. The Team members can mutually decide the WIP limit at the beginning based on the team size and available skill set. And this Limit is subject to revision after a certain period of time.

Split the WIP Columns.

It’s always good practice to split the WIP Limit into two areas 1. Doing
2. Done This split will make the status of WIP more visible and prominent. And help the team to make their strategy.
The done state of the Left column is the backlog for the right column. For Example, the stories underdone state of Development are the backlog for testing.

Understanding the Pull Based System

As we discussed earlier, Kanban is a pull-based system. Implementing the WIP Limit, active the Pull-based system. That means Thew team pulls a new task to its WIP column based on its current tasks and limits. Even if there are rooms in the current column, the team decides to pull a new story/task or finish the existing stories or tasks in the column. The below three-picture demonstrates three scenarios, where the developer or tester has the opportunity can pull a new story or task. To understand it better, please watch the video on Understanding Kanban System. later in his section.

Working with Beyond Control WIP

So far we have talked about Work in Progress like Analysis, Development, testing, etc. The execution under this column is always controlled by the Kanban Team. However, Sometimes the team wanted to have a column for other purposes, before moving it to do, for example, UAT. The work under this UAT column may not be controlled by the team, as the task or stories has to be executed by the end customer or client. If we implement a WIP limit for this UAT column, it will become a bottleneck for the team, as the stories from UAT to the next column may take time, depending upon the customer’s other priority of work and available time. To overcome this bottleneck, we set the limit of columns like UAT to infinite.  to allow the task’s free flow to this

Policies or Exit Criteria

If you have earlier worked on Scrum, you must be familiar with the definition of ready. which is a checklist we use to review our story before marking it as “Done”. For Kanban, we use a similar concept, that we call policies or exit criteria. and instead of having it only before done. We prepare the exit criteria for all the done states within each work in progress. As each WIP column has two sections “Doing” and “Done”. We implement the gate for each story from done to do. So we will have a policy of Analysis done,  another policy for Dev done, and another for Testing Done.

An example for a Dev Done could be

1. All code has to be reviewed, and Review Comments should have been uploaded to some repository
2. All code has to be checked in and Merged with the QA branch
3. the Latest code should have been deployed to the QA environment.
4. x person should have been notified by email.
5. Unit test results should have been updated somewhere.
6. etc.

The Team member mutually decides the policies for optimizing the work and performance and are subject to revision after a certain period of time.

Expedite Lane

During our Regular work and priority, we are often responsible and accountable for resolving production support issues with different severity. and many other high-priority activities come to our plate from management with an immediate resolution. To work on those high-priority work by overriding the WIP limit, we keep a reserved Swim Lane for all those kinds of work. and we call it Expedite Lane or Priority Lane. And reserve a number of tasks for that lane on top of each column.

In this example here, our Expedite Lane can add 2 more tasks on top of the WIP limit of each column. So even if the Dev limit is 4 and the developers are already working on 4 stories, they can still pick additional two stories if any stories can classify as High priority or eligible to work on expediting base. Depending upon the frequency of those high-priority tickets, Issues, Tasks, and Stories the team member can define the additional limit of Expedite Lane. and that Limit is again subject to revision in the future. The Team can prepare a definition of eligibility to treat a work item as priority work. and classify the work as a priority item accordingly.

Making the Strategy (Class of Service)

So far you learned how to work on kanban to maintain a sustainable and optimized flow of stories and work items.

The Team always makes the strategy to finish first and start later, which means teams focus on working and finishing the already started work and then plan to start afresh work. with the exception of any expedited work. To start a new job, you look into the backlog and find there is a number of work items available on the backlog or to-do list. so you need to make a strategy every day during stand-up, which item to start, and also which item you need to focus on completing faster, keeping the WIP limit in time. To simplify the strategy, we categorize our work items into 4 different areas or classes of service, as below.

By categorizing the source of work in the above four areas, you will be able to optimize the flow and pull work items into work in-Progress as it best fits your business needs. If your ALM tool supports making separate swim lanes, you can create it accordingly, however even if it does not support it or you are using a Physical Kanban board, you can color code the story or tasks for different categories of work. I will try to explain this in my video tutorial on ALM tools. All the video tutorials are at the bottom of this page.

Benefits of Kanban

Kanban is useful and beneficial if you use it to cater to the work items that best fit Kanban. like Production support, Requests, unplanned work, portfolio or program level works, etc. A few of its important benefits are mentioned below.

Scrum Vs Kanban

Assuming you are already familiar with Scrum, here are a few differences between Scrum and Kanban

Kanban Metrics

Cycle Time

When your stories or work items travel on kanban flow, from the first stage to the last stage, its flows through multiple stages. It stays within one stage for a longer time or a shorter time.

We calculate the cycle time of a story by calculating the time between

It entered the first WIP column. and leave the last WIP column in control (UAT is treated as Out-of-control WIP). It should be calculated based on the team spent actually working on this item, not how much time it was on the board. In this example on the right, the total time a story or work item spent in Development and Testing is the cycle time of the story. We don’t calculate cycle time for those stories which are still in progress or not started. We usually take an average of all the eligible stories’ cycle times to calculate the team’s cycle time for a given period.

Lead Time

This is similar to cycle time, but the only difference is, that it gets calculated from when the work item/story was created, or requested by the client and the time when it was delivered to the client. This time is also called Customer lead time. From the example on right, the lead time is calculated as the time between a story entering into the board and leaving the UAT column (Done means delivered to Customer). We usually take an average of all the eligible stories’ lead times to calculate the team’s cycle time for a given period.

Response Time
This is again calculated as the time a story/work item waited on a to-do list. The time between it was created and got the first Response by moving it to In Progress.

Throughput

Throughput is not a known measurement metric. This metric is the number of stories completed in a given time frame, Week, Month, etc.
Completed means the story/work item is completed or delivered to the client. It’s real data, not an assumption or prediction. Throughput is the number (count) of stories or work items that the team is capable of delivering in a given time period, e.g. week, or month, provided that they keep a bearable workload. It’s not a Velocity (velocity calculates on Story Point per sprint, usually measured on Scrum or XP framework) Throughput calculates on Count. The Kanban system doesn’t refer to estimates or plans. However, it’s used for measuring the performance of the team and utilization of Kanban to improve. There are many interesting formulas we must learn on throughput, I will talk about some formulas and little’s Law, in some other articles. Remember: The higher the Throughput, the shorter the Lead time

Cumulative Flow Diagram

A cumulative flow diagram is one of the valuable metrics to visualize the health of Kanban flow. It gives the view of cycle time, Lead time, and Response time, in addition to the benefits of WIP limit results. A cumulative flow diagram is a multi-layer Area chart, that represents different colors of stages on the Kanban board. The X-axis denotes the time (plot on the latest week, month, etc.). And the Y-axis denotes the number of stories on each stage. The CFD (Cumulative flow diagram) for Kanban shows one or two stages (Left most stages on the board) at the very beginning of the project, and after a couple of days, its shows the story count from stages on the relatively right side. That’s natural because we start our work with analysis then development then review then testing order. The CFD diagram always goes up from left to right.  As it always adds the current day’s work-item count under any stage with the previous day’s count of that stage. That is why the name is “Cumulative’. You will notice the color of Stages that don’t have a WIP limit keeps on increasing on their width, while the color of the stages that have WIP limits is relatively consistent on their width. From the below-mentioned picture, you can notice how the Cycle time, Lead time is calculated, and WIP areas are calculated. To understand better on CFD diagram, please watch the video Understanding Kanban. I have explained the Kanban Metrics in detail in the later section of the Video.

Videos on Kanban