Every system operates under specific conditions, including Kanban with Flow Metrics.

Of the 4 Flow Metrics, it is important to understand that Kanban with Flow Metrics is supported by Little’s Law. Little’s Law states that the average number of customers in a stable system is equal to the average arrival rate multiplied by the average time a customer spends in the system. To uphold Little’s Law, the system must be in a steady-state condition.

In the world of Kanban, this is represented by the equation:

Average Cycle Time = Average Work in Progress / Average Throughput

According to The Kanban Pocket Guide, there are 5 assumptions that must be made to achieve a steady-state condition:

  1. The average input rate should be equal to the average output rate.
  2. All work that is started will eventually exit the system.
  3. The amount of Work in Progress (WIP) should remain relatively constant throughout the observed time interval.
  4. The average age of WIP should neither decrease nor increase.
  5. Cycle Time, WIP, and Throughput must all be measured using the same unit.

To ensure these assumptions are met and the system remains predictable, certain policies must be established, such as actively controlling the Work Item Age.

Unfortunately, we live in a non-deterministic world. No matter how diligently we strive to protect these assumptions, there may be times when the system deviates from a steady-state condition. As a result, forecasting can sometimes be inaccurate.

Flow Metrics help us overcome deterministic thinking and adopt a more probabilistic approach. It’s important to remember that each work item is merely a hypothesis of value. Its true validation only occurs when it is released to users. Even after release, it may not always meet the user’s needs. Therefore, maintaining a smooth workflow facilitates frequent validation with users and allows for continuous feedback.

To feel comfortable with Kanban and Flow Metrics, our mindset must transition from being predominantly predictive to being more adaptive. Instead of relying on extensive upfront planning, it is crucial to remain calm when faced with unexpected behaviour. In fact, such situations present an opportunity to uncover new unknowns. Breaking down work items into smaller pieces minimises their age and ensures a smooth workflow.

Over time, my team has learned to prioritise the Sprint Goal rather than committing to a specific scope, unlike other teams. With a clear Sprint Goal, a well-sliced set of Product Backlog Items, and a well-constructed spreadsheet incorporating Flow Metrics and Monte Carlo simulations, there is little need for extensive discussion during Sprint Planning. We are able to complete Sprint Planning in under 20 minutes and proceed with the actual work.

However, it is important to note that these prerequisites are not absolute requirements. As long as we have done our best with the knowledge we currently possess, it is sufficient.