Last month, I wrote a blog post about why I have refrained from using Story Points and capacity estimation in my team since day one. I have been delving deeper into Kanban and immersing myself in the materials, and I have started implementing it. After introducing Kanban and Flow Metrics to my team, I received a lot of questions and feedback from them.
Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example.
In Kanban, a work item is an individual unit of value that moves through the workflow. In the context of Scrum, it can be a Product Backlog Item. The work item is a hypothesis that needs to be delivered to the users so that we can validate if it meets their needs. The shorter the feedback loop, the shorter the Time-to-Market the team can achieve. This means we should control the work in progress (WIP) and ensure that work items don’t unnecessarily age.
There are four mandatory flow metrics to assess the health of the team’s Kanban system.
WIP is the number of work items started but not finished. If there are too many WIPs, people tend to switch back and forth between multiple work items. Research from Gerald Weinberg’s book, “Quality Software Management: Systems Thinking,” shows that 40% of the effort is lost when a person is working on three projects simultaneously. Context switching is so costly that we must set a limit on it, whether it is set for the entire system, a column, or a person.
Cycle Time represents the amount of elapsed time between when a work item started and when it finished. When I introduced Cycle Time to my colleagues, they often asked me whether we should ignore holidays. The founder of Flow Metrics said we should use calendar days instead of business days. Normally, customers think in calendar days instead of business days. When they think of 30 days, it means a month rather than six weeks. Using elapsed time reduces communication problems. Second, counting business days may lead us to ignore the amount of time waited and delayed. After the clarification, my team agreed that using elapsed time encourages us not to leave the work item unfinished before the end of Friday, or else two more days will be counted. This keeps our flow much smoother.
Throughput is the number of finished work items per unit of time. It is similar to story-point-based velocity. Throughput measures the number of work items regardless of their size. This metric helps project the Service Level Expectation and answer frequently asked questions like “How many items can be done?”
Work Item Age is similar to Cycle Time but measures the amount of elapsed time between when a work item starts and the current time. Measuring Cycle Time is important, but the data can’t be realised until the work item is done. Work Item Age overcomes this limitation. It is the most important metric among the four and should be checked daily. Actively controlling the Work Item Age can shorten the Cycle Time, increase the Throughput, and gather feedback much faster. WIP can also be reduced naturally.
My next book to read
These are the basics of the four key Flow Metrics of the Kanban system. Next, I’ll write about how I worked with my team using these metrics and address common questions asked after I introduced the system.