One of the powerful aspects of Kanban is the statistical analysis of its metrics. This presentation talks about common Kanban metrics and how to interpret them.
12. Questions
In the video, what was:
Cycle time?
Work in progress?
What was the relationship
between them?
13. Little’s Law
Comes from queuing theory
Requires some assumptions
All of these values are averages, not absolutes
Cycle Time = WIP ÷ Throughput
17. Stable System
Measurements are in consistent units
During measurement period:
Work in progress total must remain steady
Work in progress average age must remain steady
Questions
What queuing approaches work for this?
What effects do class of service have on this?
What things are not implied by Little’s Law?
18. Queue Discipline
In software, we deal with non-homogenous:
Delays
Task durations
19. Continuous Flow
Little’s Law was originally proven for arrivals
To apply it to departures:
average arrival rate ≅ average departure rate
and
must be a closed system
30. How many stories need to
be completed each day to
make our release date?
31. Healthy CFD Patterns
Lines for each step become parallel
Steady Takt time synchronized effort
Gap between lines narrows
Decreasing work in process
Slope of lines increases
Throughput increasing through faster processing
By adding capacity
directly (e.g. adding people) or
indirectly (improve the process)
By lowering work in progress
By adding capacity
directly (e.g. adding people) or
indirectly (improve the process)
By lowering work in progress
Tough: product delivery has non-homogenous delays and task duration times queue discipline is crucial
FIFO or maybe round robin
Class of service implies different handling different average ages
Little’s Law doesn’t talk about size of items, people working on items, order of work, distribution of arrival & departure rates (http://vimeo.com/52683659)
http://brodzinski.com/2013/07/cumulative-flow-diagram.html
Lines wider, more WIP, slower delivery
Or maybe there are more blocked stories
Or maybe the team just grew and people are ramping up
Dev takes longer than test. Why?
Could be an issue with dev taking too long
Could be an issue with not enough QA
A dev done column might help
Done is stair-step, which implies a gated release process
More stuff in test without being released is problematic – lower quality? Devs start working on new stuff over bug fixing? Code hard to deploy?
Flat spot, company holiday?
Something blocking all stories?
Loss of staging environment?
Another project took priority?
Dev is healthy, but test is flat problem is in testing