Siddharth Goswami

Siddharth Goswami

Recent Posts

How to measure the progress of a Kanban project

Posted by Siddharth Goswami on Jan 4, 2018 12:12:00 PM

Before we jump to the core Kanban metrics, I would like to touch upon the core principles of Kanban development. They are: 

  • Visualize the workflow

  • Limit WIP

  • Continuous measurement and improvement of the life cycle

 

We have covered the first two principles in a previous blog post, Getting Started with a Kanban Project on JIRA. We will cover the third principle in this post: how to measure the performance of a Kanban project and how to improve upon it. 

Kanban Metrics to Track

Let’s look at the Kanban flow-chart from the perspective of a treasure hunt.

The game has which several teams that are competing to find the treasure by solving five puzzles at various stages, and procuring the treasure at the end of the last stage. All the teams will begin at the same time and will be given the same puzzle to solve. The team that reaches the treasure in the shortest time will be declared the winner. The shortest possible time can only be achieved when a team completes each of the five puzzles faster than the other teams. In order to gain lead time over the other teams, each team has to solve each puzzle faster than the others. 

Therefore,

Best Lead Time = Min(Cycle Time at Stage 1) + Min(Cycle Time at Stage 2) + Min(Cycle Time at Stage 3) + Min(Cycle Time at Stage 4) + Min(Cycle Time at Stage 5)

The below-mentioned definition will explain the Lead Time and Cycle Time in a better way for a Kanban project:

  • Lead time: This tells you how much time it will take to finish the task after it is received from the customer.

  • Cycle time: This is the time required to complete a certain task after the developer starts work on it. 

 

If we relate the above example to any Kanban project, the development team will have to focus on achieving a minimum lead time by continuously focusing on reducing the cycle time for each of the work in progress processes (Development, Theming, Testing, UAT). 

The Scrum Master of the project will then have to keep a regular check on these two primary metrics and share it with the development team so as to analyze the ongoing performance of the team. It is always advisable for the team to log performance on these Kanban metrics over a period of time for comparative analysis. The team will then be able to identify bottlenecks/obstacles easily and suggest performance improvement areas.

Reporting for Kanban teams

There are two common reports that Kanban teams should use: 

  • Control charts
  • Cumulative flow diagrams

Control Charts

A control chart report helps the team to keep track of the cycle time for each of the issues plus the rolling average (lead time) for the set of issues in the development process. Here’s a control chart for one of our projects:

image3_3       
 Figure 1: A control chart report helps a team keep track of the cycle time for
        each of the issues plus the rolling average (lead time) for the set of issues in
the development process 

The red line in the chart indicates the Average Cycle Time for a given set of issues in the development process over a specific period of time. The blue line shows the rolling average cycle time. The rolling average is issue-based, not time-based. For every issue shown on the chart, the rolling average (at that point in time) is calculated by taking the issue itself, X issues before the issue and X issues after the issue, and then averaging their cycle times. Twenty percent of the total issues displayed (always an odd number and a minimum of 5 issues) is used in the calculation.

For example, in the screenshot above, at the point of time where an issue (green dot) is shown, the rolling average is calculated as follows:

  • Take the issue plus 6 issues before and 6 issues after (6 issues total).

  • Average the cycle times for the 13 issues.

  • Map the blue line to the calculated average.

  • If the Timeframe is reduced to 'Past two weeks', the number of issues used would reduce, as there are fewer total issues available to use for the calculations.

Tips for the Scrum Master

  • The team's goal is to focus on reducing the time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success.
  • The closer the rolling average line is to the average line, the greater the control the team has over the process. And greater the precision in releasing tasks over a defined period of time.
  • Spot the Outliers: As the name suggests, outliers are issues that lie outside the standard range of resolution time. These are also the issues that can be easily spotted on the control chart as they are the ones that lie in the white area. The Scrum Master should notify the team of these outliers and find a way to resolve these issues as these impact the Average Rolling Time in the control chart.

Cumulative Flow Diagram

The second type of report that a team can use is the cumulative flow diagram, which shows the number of issues in each state. A team can easily spot blockages by seeing the number of issues increasing in any given state. Issues in intermediate states such as "In Progress" are not yet shipped to customers, and a blockage in these states can increase the likelihood of conflicts while delivering tasks to production. 

Here’s a sample cumulative flow diagram:

image1_4
 Figure 2: Using the Cumulative Flow Diagram, a team can easily spot
    blockages by seeing the number of issues increasing in any given state

SMs must keep a track of this flow diagram to understand the Kanban progress. This diagram can give various insights into the current state of the project. Let’s try to understand this with the help of another cumulative diagram shown below:

Cumulative flow diagram: Kanban metrics and reporting

There are five stages in the above cumulative flow diagram: In Dev, In theming, For Code Review, In QA and UAT. By looking at the graph, an SM can see that the number of issues in the UAT stage are on the rise, and sufficient UAT isn’t happening in the development process. Thus, it requires for an action item to nudge the UAT contact person to speed up the UAT process. The primary objective in a Kanban project is to keep the flow ticking by spotting and removing such blockages.

The Kanban Board has only two reports - control charts and cumulative flow diagram - as compared to the Scrum Board, but these reports give sufficient insights for an SM to keep a project on track by monitoring performance indices like Cycle Time, Lead Time and Average Cycle Time.

So there you have it, two well-defined ways to monitor and report the progress of a Kanban project. Of course, based on your particular project requirements, and the level of visibility you want, you might wish to customize these reporting formats. 

Are there any other Kanban metrics that you monitor, or methods that your team uses to measure project progress? Let me know in the comments below.

Topics: Project Management

How to follow the Kanban process for software development using JIRA

Posted by Siddharth Goswami on Dec 18, 2017 1:44:00 PM

The word 'Kanban' stands for 'signboard' or 'billboard' in Japan, which signifies some information. It was introduced by Taiichi Ohno (Industry Engineer, Toyota) to achieve “just-in-time” (JIT) manufacturing.

In the 1940s, Toyota started studying the supermarkets' self-stocking technique which they thought could be applied to their factory floor to improve manufacturing efficiency.

Pull-technique

                 Fig.1: Self-Stocking Technique of Supermarket Supply Chain


One of the essentials of any supermarket stores is to keep a track of the stocks maintained on the shelf. Ideally, the stocks on the floor should never exhaust and the product must be available for the customers to buy. 

Here’s how it was done:

  • Whenever stock on a supermarket shelf fell below a certain number, a red Kanban card was placed on the shelf.

  • This card signaled the need for new stock to be brought it from the store inventory

  • This, in turn, signaled the inventory-in-charge to get the same number of stocks from the factory

  • A Red Kanban card is added for each unit fall below the defined minimum stocks. An upper limit of cards is defined for each product type. Once there are that many cards on a shelf, it’s a signal for immediate restocking, without any delay.

 

This was the Pull Technique of stock replenishment, driven by customer demand.

The system is considered efficient if more and more shelves are well-stocked, and able to meet customer demand. This means, the goal of the Kanban process is to decrease the number of Red Kanban cards in circulation.

How to Set Up a Kanban Board in JIRA

Agile software development teams started leveraging the same JIT principles by matching the amount of "Work in progress" (WIP) work items to the team's capacity. 

Let’s understand Kanban Process in a software development project through an illustration. Let’s assume that there is a team, with two developers and one QA, who must complete 200 tasks to meet the project goals. 

To complete a task, it must traverse through the following statuses: 

  1. To-Do

  2. In Development

  3. Code Review

  4. Testing 

  5. UAT

  6. Done

The software team needs to define the ideal number of work items that they need to pick, in accordance with the team’s capacity. They need to have some kind of a signaling mechanism like a Red Kanban Card. In order to achieve that, the software development team started using Kanban Boards with WIP limits (max and min) for each of the above mentioned statuses. 

image1_1

To-Do: With the current understanding of the project and the given maturity of the team members, it is discovered that a developer will only be able to focus on 7 tasks in each release cycle. Hence, the WIP limit (Max) for the To-Do column becomes 14. 

This is added to the Kanban board (see screenshot):

image5_1                                                  Fig 2: WIP Limit(MAX) Added to the 'To-Do' Column

Also, to keep the work ticking, there must at least 3 tasks for each of the developers which bring in the factor of WIP (Min) = 6. 

Whenever the ‘To-Do’ exceeds this max limit of 14 tickets or goes below the min limit of 6, the column will turn red to notify the team to subtract or add a work item from the ‘To-Do’ column. The color ‘Red’ of the column will indicate the bottleneck in the workflow. 

Please see the screenshot below reference:

image2_3                                                     Fig 3: WIP Limit(min) Added to the 'To-Do' Column

In-Dev: Multitasking kills efficiency. When you overload the team members with more work, there are more chances of introducing errors into the system. 

So, if you are using the Kanban Board, you can make a rule that a developer will never work on more than two tasks at a moment. Therefore, the WIP (Max) for ‘In-Dev’ = 2. This will reduce the impact of context switching and will help the team to complete the tasks quicker.

Testing: Similarly, there should not be more than 3 tasks in ‘Testing’ Column for a single QA to work on at a given point in time. If there are more than 3 tasks in the ‘Testing’ column. This implies that there is some bottleneck in the flow which calls for an improvement. 

Therefore, the WIP (Max) and WIP (MIN) for the ‘Testing’ column becomes 3 and 1, respectively. 

In the same manner, the WIP limit can be defined for all the significant column. The Project Owner(PO) and Scrum Master(SM) can together study the capacity of the team and decide the WIP limit they would want to set on the planning board columns. Let’s take a look the execution board after the WIP limits for the all the statuses have been set:

image4_1
Fig 4: The complete view of the Execution Board with WIP Limits for the different columns

At any given point of time in the execution of the project whenever the WIP Limits are exceeded, the corresponding will turn red in order to notify the team of the blockage on the workflow, thus, ensuring the smooth flow of tasks on the execution board.

Please see the below screenshot for reference:

image3_2

The boards need to be monitored on a regular basis to ensure that work flows smoothly. As the project environment keeps changing over the course of time, the workflow and the WIP limit of the board are supposed to change accordingly. 

For example: A senior developer of the team exits the team and a new developer comes in to work on the project. This new team member comes with a different skill set and has limited knowledge of the project, which might lower the WIP Limit. The scrum masters are required to monitor the control chart on regular basis during this duration till a set equilibrium of WIP limit gets established.

Once the workflow (columns of the board) and the WIP limit has been decided, the project is set to roll. With this information in hand, the SMs would be enabled to monitor, control and act upon the blockages identified on the execution board. 

This is a good start for working with a Kanban board. In my next post, I will cover the Kanban metrics to monitor, and how to measure project progress.

Meanwhile, do you have any tips or suggestions on how you use the Kanban board for your team? Or any questions about starting off with Kanban? Please let me know in the comments below.

Topics: Project Management, Agile

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us