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.
Its a Method of Visualize the flow of work.
in order to balance demand with available capacity and spot bottlenecks
This frame work is highly productive and effective to run ..
- Ad-hoc Requests,
- Unplanned works,
- Production Support
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 inventory with demand and achieve higher levels of quality and throughput.
Kanban, also spelt kamban, 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 produce.
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 this principles, and its benefit later in this course. You can also watch the Video tutorials to get a deep dive.
Implementing software increment on Kanban Method is a pull based system, that help the team to Continue the delivery in a sustainable pace, with in capacity. Its reduce waste of efforts 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 make the scope and capaicty transparent, it helps to observe and Inspect the flow of work moving backlog to done. This makes the work visible—along with blockers, bottlenecks and queues and upcoming work, Which helps the team to make strategy of working on exiting work or bring new work to 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 previous column only if the total number of work 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. Its reduce waste and help the team to focusing on finishing first and starting later.
3. Focus on flow of Work
To Complete a work, and add a 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 flow of work from its initiation to completion. By following 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. Team frequently makes strategy of working on in progress wor item to optimize the flow
We already learn the basics of Kanban and its principle, lets try to relate the Kanban flow with Real life. Assuming you already know and practicing scrum, where we do Iterations of defined timebox. we commit bundle of stories, work on them for 2 to 3 weeks and complete the Iteration and again plan for new bunch of stories for next iteration. In Kanban we dont commit stories for iteration or time box or sprint. we do it little differently.
In the below example we will relate Scum and Kanban with real life. Lets assume the people are the stories a movie Theater is a Iteration, Show time is iteration
Relating Scrum flow with Real life
This Scenario explains the flow of people in a move Theater in a bunch of people at once. If we assume the peoples are user stories and Show time as Iteration or time box. Then you may able to notice that the group of people peoples are going in a Movie theater together and coming out together. We have a defined seat capacity and show time. The people planned for each show is pre -planned before the show starts.
Relating Kanban flow with Real life
This Scenario explains the flow of people in a Public Park one by one permitted by the gate keeper. If we assume the peoples are user stories, The Park is the Kanban Board. Then you may able to notice there is no defined show time of the park, as it is open 24 hours. The people going in or Roaming inside the park and coming out is not in a group. We don’t have capacity and show time. 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, lets try to relate the scenario in Scrum terminology. If we assume the peoples are User stories, Then the people waiting outside the Hall for future show are lists of User stories in Backlog. The Active Move Theater show is the Active Sprint or Iteration. The People watching the Show are the Stories of active sprint. The Show time 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 identified as released or already deployed.
And here lets 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. Show time is not defined, Max Capacity is unlimited, however Management has decided not to allow more than 6 stories in the board. People already moved out from the park are ate completed user stories ready to deploy. The management is taking a count of stories coming out, to allow that many stories move in. No defined start or end date of 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.
Now Lets jump into the play. we got an fare idea of Kanban and its rules, principle. Lets 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 have the work visible and transparent to all, we need to have a board of works , it can be physical (better for co-located team). How ever now a days most teams are situated distributed location, So we can have a digital board. You can use you ALM tool to configure a board like that.
Later 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 implement with in those ALM.
A Kanban Board typically have three main Sections
- Todo (or the Backlog)
- In Progress (The Work in Progress Area)
- Done (The Stories those are completed.
Implementing Multiple WIP Columns
How ever 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 section Development and Testing.
You can make the distribution as per your need and teams comfort to have a better control. This Distribution to more than one column always helps implement the WIP Limit for different skillset.
Implementing WIP Limits
Limiting the count of Stories for Work in Progress Column is one of the core principle 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 as 4 and max stories for testing is 3. That means the team can work on max of 4 stories under development column and max of three stories under 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 on development with limit of 4 and 3 stories under testing with limit of 3. So in this case even the developer completes the development of 1 or more stories, They can not pick new stories from Backlog, as there are no room for new story or task under development.
To make room on development column testers need to pull one or more stories or tasks from Dev to testing. and the Tester can only do that, if the complete the testing of some existing story/task and move it to done state.
In this senario the Developer will not seat Ideal. The will contribute their efforts to tester and expidite the testing so the team can pull stories from development, and 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 revise after certain period of time.
Split the WIP Columns.
Its always a good practice of splitting the WIP Limit by two areas
This split will make the status of WIP more visible and prominant. And help the team to make their strategy.
Done state of the Left column is the backlog for right column.
For Example, The stories under done 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 there are rooms in the current column, the team decide to pull a new story/task or finish the existing stories or task in the column.
The below three picture demonstrate three scenario, where the developer or tester have the opportunity can pull new story or task.
To understand it better, Please watch the video on Understanding Kanban System. later int 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 purpose , before moving it to done, for an 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 end customer or client.
If we implement a WIP limit for this UAT column, it will become a bottle neck for the team, as the stories from UAT to next column may take times, depend upon customer’s other priority of work and available time.
To overcome from this situation of bottleneck, we set the limit of columns like UAT to infinite. to allow the task’s free flow to this column
Policies or Exit Criteria
If you have earlier worked on Scrum, you must be familiar with 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 as policies or exit criteria. and instead of having it at only before done. We prepare the exit criteria for all the done sate with in each work in progress.
As each WIP columns have two sections of “Doing” and “Done”. we implement the gate for each story from doing to done.
So we will have a policies of Analysis done, another policy for Dev done , and another for Testing Done.
The example for a Dev Done could be
- All code has to be reviewed, and Review Comments should have uploaded in some repository
- All code has to be checked in and Merged with QA branch
- the Latest code should have deployed to QA environment.
- x person should have notified by email.
- Unit test result should have updated to somewhere.
The Team member mutually decide the policies for optimize the work and performance and and subject to revise after certain period of time.
During our Regular work and priority we often responsible and accountable for resolving production support issues with different severity. and many other high priority activity comes in our plate from management with immediate resolution.
To work on those high priority work by overriding the WIP limit, we keep a reserved Swim lane for all those kind of work. and we call it as 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 columns. So even the Dev limit is 4 and the developers are already working on 4 stories, They can still pick addition two stories if any stories can classify as High priority or eligible to work on expedite base.
Depends upon the frequency of those high priority tickets, issues, Tasks, Stories the team member can define the additional limit of Expedite Lane. and that Limit is again subject to revise in future.
The Team can prepare a definition of eligibility to treat a work item as priority work. and classify the work as 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, that means teams focus on working and finishing the already started work and then plan for start a fresh work. with exception of any expedite work.
To start a new work, you look into the backlog and found there are numbers of work items available on the backlog or to-do list. so you need to make a strategy everyday 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 on 4 different areas or class of service, as below.
Class of Service
The Regular as usual stories or work items.
The High priority work items like, Severity one Production issue. This goes on Priority or expedite lane.
Stories having fixed completion date. Sometimes Penalty clause associate with this kind of stories. In case business needs something on or before some specific date, and available on backlog way in advance. the team can make the strategic, to the bring the work item in Progress accordingly.
These are the work items, which does not add immediate value to the business but have a long term benefits. most maintenance work falls under this category. example 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 on the above four areas, you will be able to optimize the flow and pull work item into work in-Progress as it best fit your business need.
If your ALM tool supports making separate swim lanes, you can create it accordingly, however even if it not supports or you are using Physical Kanban board, you can color code the story or tasks for different category of work.
I will try to explain this on my video tutorial on ALM tools. All the video tutorials are at the bottom of this page.
When your stories or work items travels on kanban flow, from first stage to last stage, its flows through multiple stage. Its stays with in one stage for a longer time or Shorter time.
We calculate the cycle time of a story by calculating the time between
its 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 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 time to calculate the team’s cycle time for a given period.
This is similar to cycle time, but only difference is, its get 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 as Customer lead time.
From the example on right, the lead time is getting calculated as the time between a story enters into the board and leave the UAT column (Done means delivered to Customer).
We usually take an average of all the eligible stories lead time to calculate the team’s cycle time for a given period.
This is again calculated as the time a story/work item was waited on todo list. The time between it was created and got the first Response by moving it to in Progress.
Throughput is not that known measurement metrics. This metrics is number of stories completed in a given time frame, Week, Month etc.
Completed means the stories/work-item completed or delivered to client. Its a real data, not on assumption or prediction.
Throughput is the number (count) of stories or work items that the team is capable to deliver in a given time period, e.g. week, month, provided that they keep a bearable work load.
Its not a Velocity (velocity calculates on Story Point per sprint, usually measured on Scrum or XP framework) Throughput calculates on Count. Kanban system don’t refer it to estimate or plan. However its useful for measuring performance of the team and utilization of Kanban to improve.
There are many interesting formulas we must learn on throughput, Will talk about some formulas and little’s Law, on some other article.
Remember : The higher the Throughput, the shorter the Lead time
Cumulative Flow Diagram
Cumulative flow diagram is one of the valuable metrics to visualize health of Kanban flow. Its gives the view of cycle time, Lead time and Response time, with addition to benefits of WIP limit results.
Cumulative flow diagram is a multi-layer Area chart, represents different colors of stages in Kanban board.
The X axis denotes the time (plot on latest week, month etc). And the Y axis denotes the amount of stories on each stage.
The CFD (Cumulative flow diagram) for Kanban shows the one or two stages (Left most stages on the board) at the very beginning of the project, and after couple of days, its shows the story count from stages on relatively right side. That’s natural because we start our work from 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 previous day’s count of that stage. That what the name is “Cumulative’.
You will notice the color of Stages don’t have a WIP limit keeps on increasing on their width, while the color of the stages have WIP limits are relatively consistent on their width.
Form the below mention picture, you can notice that, how the Cycle time, Lead time are calculated, and WIP areas are calculated.
To understand better on CFD diagram, please watch the video of Understanding Kanban. I have explain about the Kanban Metrics in details at the later section of the Video.