You already use a Kanban board for your Agile project. It’s good. But to manage it, you will need concrete elements, like metrics. In this post, I will present the main metrics used to improve the fluidity of the board. In other posts, I will discuss the more technical metrics of the software or the metrics more related to the atmosphere of the team.
The metrics presented are Burn Up Charts, Burn Down Charts, Velocity, Cycle Time, Cumulative Flow and Process Cycle Efficiency. Each one has is interesting and can answer specific questions.
The burn charts exist in two variants:
- the burn-up chart: it represents the amount of work done - so it rises towards the target
- the burn-down chart: it represents the amount of work remaining to be done - so it goes down to zero
The burn charts help to ensure that the team moves the tickets forward throughout the process. They highlight the moments when the team accumulates unfinished work, thus making it possible to seek to identify the causes.
They allow :
- to adjust the WIP limits to streamline the continuous flow of tickets,
- to identify irregularities in the ticket flow and in their processing,
- to visualize the work of the team
Velocity allows you to measure the work produced by the team at each iteration.
Velocity (“velocity”) represents the amount of work performed by iteration. Controlling this velocity improves the predictability of planning.
It is based on several conditions:
- Iterations are time-boxed.
- Iterations have a fixed length.
- The productions of each iteration (“increments”) are ready to go into production (“definition of done”).
- Tickets (“User Stories”) are estimated in terms of effort or they are similar in size - in which case the measure can be simply the number of tickets.
- The composition of the team remains almost constant.
Velocity is a measure specific to each team. This value cannot be compared with the velocity of another team. Its value is based on the empirical observation of its performance in the recent past - so the reality. It is therefore unknown - or unreliable - in the very first iterations. It is at the end of the 3rd or 4th iteration that the value of the velocity will begin to be stable.
The cycle time is used to measure the average time to complete a ticket. This is an excellent tool to highlight opportunities for improving team practices.
You must have two goals on the cycle time.
The first one is to reduce the cycle time variations. Consistency helps reducing waste. The second is to reduce its value, which allows to increase the flow, and therefore the time to market.
The Cumulative Flow visually represents the fluidity of the work, in order to reduce the bottlenecks.
It provides a visual representation of the throughput, turnaround time, cycle time, queue size, and remaining work. The more a region of the graph becomes larger, the more there is a bottleneck in the process.
The Cumulative Flow interpretation can identify periods of insufficient resources disrupting the work of the team. It also allows to identify possible “bus number” phenomena, occurring when the tickets are waiting for rare skills. Finally, it identifies the most appropriate WIP limits. WIP too high leads to the accumulation of unfinished work. On the contrary, a weak WIP leads to an irregular flow. We must find the right environment.
According to the Theory of Constraints, each system has at least one constraint (bottleneck). To exploit the Cumulative Flow results, we use the principle of the five focusing stages:
- Identify the constraint.
- The Cumulative Flow makes it possible to identify it.
- It appears as a narrow band with a wide band just in front -of it.
- Use the constraint: it defines the rhythm of the whole process.
- Make sure all necessary resources are at their maximum capacity.
- Any delay in the constraint causes a delay in the whole process.
- To absorb delays, you can use queues between steps.
- Subordinate the process to the constraint.
- Avoid the other steps of the process working faster than the constraint. For this you can create a WIP.
- Increase the capacity of the constraint.
- Analyze the root causes.
- Make changes in your process, resource allocation or technical practices.
Process Cycle Efficiency measures the proportion of time during which value is created relative to the total execution time. It identifies where time is wasted for a non-value-added activity, ie waiting times or time costs of context changes for example.
In other words, the PCE makes it possible to measure the proportion of effective working days on a ticket compared to the total processing time of the ticket. This is the ratio of the number of days that the team actually worked on the ticket on Cycle Time. For information, its usual value in the industry is around 10 to 15%, before being optimized.
The PCE is based on the Little’s Law from Queuing Theory, which states that the average number of clients in a stable system is equal to their average arrival frequency multiplied by their average time spent in the system.
Now you have all the tools in hand to better control the Kanban board of your project. You just need to get the input data for these tools. You can use software tools like JIRA or TFS, or use a simple Excel file that traces the history and produces measurements and graphs. Let’s go!