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.

Normal The Regular as-usual stories or work items.

Expedited The High priority work items like the Severity of one Production issue. This goes on the Priority or expedites lane.

Time-Bound Stories have a fixed completion date. Sometimes Penalty clause is associated with this kind of story. In case the business needs something on or before some specific date and is available on backlog way in advance. the team can make the strategy, to bring the work item in Progress accordingly.

Intangible

These are the work items, which do not add immediate value to the business but have long-term benefits. most maintenance work falls under this category. Examples could be, Database migration from Server A to Server B, Re-indexing the database. Getting backup of production date to test environment.

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.


Planning flexibility

A Kanban team is only focused on the work that’s currently in progress. Once the team completes a work item, they pull the next work item off the top of the backlog. The owner/stakeholders are free to re-prioritize work in the backlog without interfering with the team, Any changes outside the current work items don’t impact the team. As long as we keep the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business.


Shortened cycle times

Cycle time is one of the key metrics for kanban teams. Cycle time is the duration of time a story/work unit takes to travel through the team’s workflow–from the moment work starts to the moment it is finished. By optimizing cycle time, the team can confidently forecast the delivery of future work

Reduce Roadblocks

Multitasking kills efficiency, That’s why a key principle of Kanban is to limit the amount of work in progress (WIP). Work-in-progress limits help visualize bottlenecks. And the team unitedly jump into resolving the roadblocks to get the flow enabled.


Continuous delivery

The CD is the practice of producing work results to customers frequently–even daily or hourly. Kanban and Continuous Delivery complement each other because both techniques focus on the just-in-time delivery of value.


Visual Metrics

Kanban System is known for its visual workflow, so the metrics like Cycle time, Throughput, etc., give end-reach transparency of the current flow, performance, and improvement opportunities to act on. We will talk about its different metrics in us later on this page.

Scrum Vs Kanban

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

SCRUM

KANBAN

Cadence / Delivery

Regular Time box in Sprints

Continuous Flow

Release Frequency

At the end of each time box or later


No defined Roles except for the development team, Some teams consult with Agile Coach

Roles

Scrum Master, Product Owner, Development Team

At the end of each time box or later

Key Metrics

Velocity

Cycle Time, Throughput, Cumulative Flow

Scope

Scope planned at Sprint Planning, in a batch with a bundle of works


Works pull into the system, one by one

Change Mechanism

Scope planned at Sprint Planning, No Changes allowed mid-sprint

Changes can be made at any time.

Applicability

More appropriate in situations where work can be prioritized in batches that can be left alone

More appropriate in operational environments with a high degree of variability in priority

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

Understanding the Basic Concept of Kanban

.

Configure Kanban Board in TFS

Configure Kanban board in Rally.

Configure Kanban Board in Jira

Niladri Mahapatra

Niladri Mahapatra

Leave a Replay

Sign up for our Newsletter

Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit

Shopping Cart

Do you know that we have an exclusive Practical program that includes a mini live Project?

A journey to become an efficient Scrum Master

Share your information, we will send you all the related information

Efficient scrum master

Our Efficient Scrum Master Course (ESM) is an exclusive course which will take you on a journey of how you can become an Efficient Scrum Master with practical knowledge

Offers and Discounts

Republic Day
Sale

ESM early bird, Flat 10% discount for ESM Courses(A & P) , Please talk with the chat agent to get the discount code.

 

On Going

SAFe.webp

Attractive Discounts and Offers on SAFe Certification

On Going

Special Discounts on Excel Template, 


Connect with our Chat Agents for more information and to grab more offers and discounts

EARN FROM YOUR SPECIALIZED SKILLS

We may not be experts on everything, but all of us have some skills that we are super experts in, It can be Agile, It can be Excel or Jira or Java or Database or Machine Learning or Project Management or UI Design, or anything else.
Sounds Interesting? wants to know more? feel this form we will contact you and explain the next step and process. Does not matter which country you belong to and which Time zone you are in we all have potential needs everywhere. 
You may be Trainer, Freelancer, Full Time Employee, or consultant. Why not you earn little extra money with your expertise on your available time. You chose what you want to do, support another professional or train a group of people or participate in a small or large project choose the skill you complete hold. On top of that, you choose the rate that you want to charge. Get yourself exposed to the people who may need your service.

Want to make a DEEP DIVE To JIRA JQL?

The Offer You Can Not Refuse
As many of us are well-acquainted with the versatility of Jira, we often encounter challenges in filtering data precisely as needed. This is where the power of Jira Query Language (JQL) becomes indispensable. I am excited to share some fundamental concepts of JQL that will empower you to craft more effective queries, enhancing your data manipulation capabilities within Jira.

Join our "Refer and Earn" program by simply filling out this form. Here’s how to get started:

You are referring to What Is Kanban? Comprehensive Guide (2023)

If there's anything else you'd like us to know about your referral, or any specific instructions, please include them here.
How do you want to get your reward
Once you’ve filled out the form, click ‘Submit & Earn’. We’ll take it from there, and you’ll be on your way to earning rewards!
Training Calendar
SAFe Transformation
Corporate Engagement

Feed back From popular courses

Azure Board Training Feedback
Thursday Virtual Collaboration
Jira Training Feedback
Sprint Simulation Feedback
Efficient Scrum Master Feedback
SAFe POPM Feedback
SAFe Advanced Scrum Master Feedback
SAFE Scrum Master Feedback
Leading SAFe Feedback

Explore our Excel Templates

Recent Blogs and Articles

Agile Digest Exclusive

PI Planning Simulation
Jira Advanced Roadmap
Working with Rally Software
Jira Service Management
Mastering Jira
Azure Boards
Efficient Scrum Master (ESM) Certifications
Sprint Simulation

Agile life cylce Management - Training

Jira Advanced Roadmap
Working with Rally Software
Jira Service Management
Azure Boards
Mastering Jira

Scaled Agile Framework (SAFe) - Certification

(SP) SAFe for Teams 6.0
Implementing SAFe (SPC)
SAFe Release Train Engineer
SAFe Lean Portfolio Management 6.0
SAFe Agile Software Engineering
SAFe Agile Product Management 6.0 (APM)
SAFe® for Architect
SAFe DevOps Practitioner
SAFe Advanced Scrum Master
SAFe Product Owner/Product Manager (POPM) 6.0
SAFe Scrum Master (SSM) 6.0
SAFe Agilist (SA) / Leading SAFe 6.0

Upcoming Training and Events at a glance