I often hear that teams following Kanban think that they have very less data points to improve their process flow since they do not plan and forecast. If you or your team is sailing in the same boat, then this post may be of interest to you-
Kanban teams have a lot of data points to inspect and adapt. Here goes the list, and believe me I really started loving this data since this information is so much meaningful to guide the teams towards continuous improvement! .
- Cycle time
- Lead time
1.Cycle time-The Cycle time is the number of days it takes for the backlog item to get done as per the team “Definition of Done” a.k.a the exit criteria of the final state in the team Kanban workflow stage.
The cycle time clock generally starts when the team starts working on the backlog item, once it is well defined for the team in terms of the functionality to be developed. Cycle time is what the team sees in terms of how much time it took to complete the given backlog item.
2.Lead time– Lead time is the elapsed time from the moment the backlog items is put into the product backlog, as against the cycle time the lead time clock starts as soon as the item in in the backlog.
Hence the lead time is what the customers see and cycle time is what the team sees.
Cycle time indicates the flow efficiency and lead time indicates the overall process time efficiency.
3.Throughput– is defined as the number of items team could finish as per the definition of done in a cadence of say one week/or one month.
4.Age– Age of card is the number of days the backlog item is in each stage of the flow. This is an important aspect that teams can consider for inspecting the trend of the flow in each stage.
The age of the card indicates the amount of time it takes for the backlog item to move to the next stage from their current state. If the cards stays longer in a particular state, then it indicates that the particular step was complex or took more time due to some bottleneck.
The age can be plotted to see which stage takes more time and how one can reduce the process time of that stage so that overall cycle time improves.
Areas of inspection- Since Kanban does not prescribe specific inspection points like Scrum and is pretty open, Kanban teams are free to choose how often they would like to inspect and on what areas as specified below
- Daily – Teams can still meet daily to check-in their plan for the day and talk about any impediments they have.
- Retrospectives- Team discusses what changes they should make to improve their Kanban efficiency and quality, and they could choose to meet weekly or monthly based on how often they feel based on their work
- Planning/Grooming – Teams can plan weekly or on any cadence to look at the priority and inflow of work items
Listed below are common questions that I see coming up, and here is my perspective-
1.How can Kanban teams measure their efficiency since they do not sprint like Scrum teams?- I believe Kanban teams get lot more insights as against the Scrum teams since they actually inspect their flow every day as compared to the Scrum teams that generally do at the end of the sprint.
2.How can I measure how many items are getting done and what is the productivity? – Teams can always use their throughput to measure their run rate. Teams can categorize their work items based on factors like complexity, type of work, effort needed, risk and value. They could define a particular cycle time for each category, and they could use the cycle time data for each of their work items during their inspection cycles to retrospect around how fast or slow is their pace and how can they improve overt time!
3.How can I visualize the blockers in Kanban? –Work in progress limits and age of the cards are very powerful indicators of the bottlenecks in the flow. I would say teams may define a threshold for each stage, and if at any time the age of the card exceeds the threshold, it is an indicator of some bottleneck.
To conclude– Bringing in transparency using a Kanban board and reflecting on the key indicators actually enables them see through the bottle necks at ease. I believe the Kanban teams have much more data than the Scrum teams for reflection!