The Kanban Applied Guide
Official Guide to Applying Kanban
as a Process Framework
May 2018
Purpose of the Kanban Applied Guide
While the number of companies who use Kanban have been increasing every year, it is still not the most commonly used process today. One of the primary reasons for this is the lack of awareness that Kanban can be used as the basis for a process framework. Moreover, there has been no official guide that defines the applicability of Kanban as a process framework. This document fills that gap.
It is not necessary for a framework to impose rules. To the contrary, flexibility in a framework is key. This allows teams to make decisions that work best for their particular team. This document serves as a guide, as a reference – and not as a set of rules.
Kanban Applied is a process framework, based on a continuous flow model, that enables teams to successfully build complex products or to efficiently execute any workflow. This guide explains a continuous flow model using WIP limits. It gives options for partitioning work, collecting metrics, forecasting, events, roles, and artifacts.
Kanban Applied Principles
Teams that execute using the Kanban Applied framework:
- use a continuous flow model, limiting WIP
- continuously pursue removing waste
- leverage both Agile and Lean principles
- continuously weigh options
- possess a strong focus on people
Continuous Flow
Perhaps the most distinguishing feature of the Kanban Applied framework, when compared with other process frameworks, is that it leverages a continuous flow model. Other popular models use either a timeboxed model or a phased approach.
Teams describe their workflow by depicting all the steps necessary to go from inception to completion. For example, in a software application, this may include all steps beginning with a customer request for a feature to the software being deployed in order to fulfill that request. The steps will vary depending on the team and on the application. The team builds a Kanban board that represents their particular workflow. The following picture is just one example of what a Kanban board might look like for a software development team.
Figure 1 Example of a Kanban Board
Teams may either start by depicting their current workflow prior to adopting the Kanban Applied framework (if one already exists) or they may define a new workflow representing what they would like it to be. It is important to note that whatever workflow the team decides to start with can and likely will change over time.
WIP Limits
The example in Figure 1 shows numbers beneath the columns (or states). These numbers represent Work In Progress (WIP) limits. Kanban team members will pull work from left to right as long as the work pulled will not exceed the WIP limits defined for the respective column.
How these WIP limits are initially set is again highly dependent on the team and its unique application. There are many approaches to initially setting WIP limits ranging from basing it on the number of people who service a column/state in the workflow to setting the limits to whatever they were prior to implementing the Kanban Applied framework. It is typically more important for a team to get started with a new Kanban board than to overanalyze setting these initial WIP limits. Moreover, the initial WIP limits set by the team can and often will change over time as the team empirically executes its workflow.
In the example above, let’s assume a developer completed work on item R. Since the Ready Test column has a WIP limit of two and only one item (Q) is in that column, the developer can move R to the Ready Test column. Now the developer can pull item X in to the In Dev column since In Dev is still under its WIP limit of 6. Work continues to move freely from left to right as long as all columns remain under their WIP limits.
What happens when a state is already at its WIP limit as in the diagram below?
Figure 2 Example exceeding WIP Limits
In this example, a developer completed item S and wants to place it in the Ready Test column. This raises a red flag that the Ready Test column is now beyond its WIP limit. It is a signal to the team that testing may not be keeping up with the pace of development.
At this point, the team should focus on fixing or removing this potential bottleneck. There can be many solutions to fixing a bottleneck ranging from adding/removing personnel to making process or technology changes. It is also possible that no change is required and that the WIP limits simply need to be modified. Once again, the specific change required is highly dependent on the team and its application.
It is important to note that Kanban does not automatically fix bottlenecks. Rather, it gives teams very simple visual tools to enable discussions to take place as soon as potential bottlenecks occur. The team can then take whatever actions they believe makes sense in order to get products to the customer in the most efficient manner.
By not allowing work to continuously pile up somewhere in the middle of the workflow, completed items are getting to the customer sooner. This is one of the primary benefits of leveraging a continuous flow model using WIP limits.
Partitioning Work
Teams may decide to partition work into multiple swimlanes for a variety of reasons based on the type of work, urgency or resources. There can be many benefits to partitioning work including enabling the team to:
- push urgent items through the workflow quickly
- schedule different types of work based on needs
- allocate team capacity against the mix of work types
- easily track metrics based on the type of work to help in future analysis and decision making
Classes of Services (Cos) is one example of partitioning work based on the Cost of Delay (CoD), or the economic impact of delaying work. The following table shows the most common Classes of Service.
| Classes of Service | |
| Expedite (aka Silver Bullet) |
|
| Fixed date |
|
| Standard |
|
| Intangible |
|
Another example of partitioning work is by work type. For example, a team may split time working on new development while adding enhancements to maintain a legacy system, while fixing low priority defects. The team would define a policy for each swimlane describing when a team member can pull items in a swimlane and associated WIP limits per swimlane. Teams may also decide to dedicate team members per swimlane or to have floating team members who can pull work in any swimlane.
These are just some examples of work partitioning. The specific utilization of work partitions will vary based on the team’s specific application.
The following picture shows an example of a team’s partition.
Figure 3 Example of a Kanban Board with Partitions
Kanban Metrics
Kanban metrics should be used by the team, not for managers/auditors to check on the team. While there are a set of common terms used by almost all Kanban teams, these terms have a variety of definitions in the industry. The Kanban Applied framework defines these terms as follows:
Cycle Time: how long a particular item takes to complete once work begins. In other words, how long an item takes to get through the workflow.
Lead Time: the clock starts when the team agrees to a customer request for a particular item and ends once delivered.
Throughput: the total number of items completed in a given time period.
Average cycle time: the average time an item takes to get through the workflow, once work begins, over a given time period. In other words, the average of the team’s cycle times.
One of the primary tools used by the team is a Cumulative Flow Diagram (CFD). CFD’s give a graphical representation of how work is flowing through the system. It shows how many items are in each state within the team’s workflow over time. It also depicts average cycle times, throughput and WIP. Finally, the CFD can be used by the team to view recurring trends.
The team may define what metrics goals they desire. Common goals include:
- minimizing cycle times (by eliminating bottlenecks in the workflow and by minimizing WIP)
- maximizing throughput (by minimizing Average Cycle Time)
As stated earlier in this document, partitioning work allows the team to easily collect and utilize metrics for different types of work – e.g., the average cycle time of new development is 7 days but the average cycle time of bug fixes is 1 day.
Forecasting Options
There are many forecasting options that Kanban teams may use in order to forecast how long it will take to complete a backlog of items. The Kanban Applied framework describes three of the most common options as a reference.
- Option 1: use throughput
- Option 2: do not bother forecasting
- Option 3: Size using S-M-L (only use when necessary)
In the first option, the team measures their throughput (number of items completed every week) and computes an average over time. The team does not size any items. The computation is simple:
Forecast = # of Backlog Items / avg # items completed in a week
Example: 100 product backlog items / 10 items average completed in a week would be forecast to take 10 weeks to complete.
Once again, when forecasting using throughput, teams may need to differentiate between Work Partitions if different work types have very different average throughput.
The second option is to not bother to forecast at all. Many backlogs change frequently (even daily) based on customer feedback or other factors. Therefore, forecasting a backlog may not provide any value. Product release decisions are typically made dynamically and may also be done frequently.
Option 3 should only be used when and if necessary. It is used when the team has a very large backlog; it would be a waste of too much time to decompose the backlog up front; and a rough estimate is required or desired for completing the entire backlog.
The team sizes all backlog Items as S-M-L.
- Small: estimated to take less than 2 weeks to complete
- Medium: estimated to take less than 1 month to complete
- Large: estimated to take less than 3 months to complete
The team does not actually work on any items unless they have been decomposed to a Small. Medium and Large items are only in the backlog in order to do course-grain (“rough”) estimates for very large product backlogs.
The same formula is used as in Option 1, however, multiply Medium items by 2 and Large by 6.
Example: A backlog contains 50 Small items, 20 Medium items, 10 Large items. The team completes 5 items each week. A rough estimate is 30 weeks to complete all items calculated as: (50/5) + (20*2)/5 + (10*6)/5 = 10+8+12 = 30 weeks.
When using option 3, teams should minimize the number of Large items. It is important to recognize that the more Medium and Large, the less accurate (it is a very rough estimate). Again, option 3 should be used sparingly and only if necessary.
The above options are just a few of the possibilities teams may use when forecasting. Other options may also be implemented.
Kanban Events
The section discusses Kanban meetings. Three overarching guidelines exist:
- Do what makes sense for your team (which may change over time).
- All teams have different needs and do not need to be “cookie cutter” across an organization.
- Reduce waste – unnecessary meetings are waste.
The following meetings are guidelines that will vary by team.
Daily meeting
Kanban Daily Meetings focus on flow of the visual board. The team should:
- look for any bottlenecks (full or empty states) on the board
- discuss any issues with the workflow not flowing smoothly (e.g., are any items blocked or slowing the team down)?
- discuss any changes team members suggest should be made to WIP limits, workflow or process
- discuss new requirements added to a backlog or ready queue that would benefit from discussion
- discuss any learnings anyone on the team wants to share and/or things they need help with
- have fun
(Optionally) the team may walk the board from right to left discussing items in each state
The duration of the meeting depends on the team and needs that day. The meeting is typically less than 15 minutes but may be followed by any issues needing more discussion.
Team interactions meetings
Team interactions are more important than processes. Teamwork, communication, positivity and morale effect cycle times more than anything else. Therefore, it is critical to hold team interactions meetings from the start of a product team forming and whenever team members change. These meetings should focus on helping the team members understand their differing communication styles, motivations and should foster trust between team members.
The team should also hold periodic retrospective meetings, looking backwards, and discussing what areas the team can improve. Areas for improvement may be related to communication, team behaviors, processes, technology or workflow. The criticality and frequency of these meetings depends on whether the team is already openly communicating about issues during the daily meetings, metrics meetings or through the course of frequent team communications. It is recommended that the team initially hold these meetings monthly or bimonthly and then modify as needed by the team.
Kanban metrics meetings
As mentioned previously, the team should collect Kanban metrics. They should meet periodically as a team to look for and discuss trends. These discussions should include ways the team can optimize or improve.
The team may also discuss their current single biggest constraint and how they can help reduce or eliminate that constraint.
The frequency and duration of these meetings depends on the team. It is recommended that the team initially hold these meetings monthly or bimonthly and then modify as needed by the team.
Other meetings (if necessary)
Periodic demonstrations may be necessary if the team is not frequently deploying or if they are not getting product feedback from stakeholders in other ways.
Backlog Refinement meetings may be scheduled if necessary in order for the team to discuss, decompose and/or prioritize requirements. One form of backlog refinement meeting is called a “Replenishment Meeting” where the team discusses and queues up the next set of items to work.
Periodic planning meetings may be scheduled if deemed important by the team.
Kanban Roles
Some Kanban teams will have a team member playing a Product Owner role responsible for what the team works on and prioritization. The Product Owner will typically add requirements to the to-do column and discuss with the team.
Some teams hold periodic meetings to discuss requirements as a team creating and maintaining their to-do column via a Replenishment Meeting as mentioned above.
Some teams include a Kanban Leader role responsible for coaching the team on team behaviors, communications and Kanban processes. The Kanban Leader may also provide facilitation for any meetings as necessary.
The Kanban Applied framework does not limit the roles required for a team to succeed. Whether or not the team defines development roles beyond the Development Team or other roles specific to the team depends on the team.
Kanban Artifacts
The primary artifact for any Kanban team is the Kanban Board itself. The construct of the board will vary by team. It visually contains all the items the team is working on and the state of all items. The board will depict any policies the team agrees to such as WIP limits per column or swimlane. The board may be electronic or may be a physical board.
End note
Kanban Applied can be used to efficiently execute any workflow or to successfully build complex products. It can be used for building software or any other application which can benefit from visualizing and managing workflow such as marketing, sales, personal use, and so on.
Use of the Kanban Applied framework and this document are free. We welcome suggestions for change and updates to this document.