John Little coined his eponymous theorem while studying queues – it links the rate at which customers enter a queue, the average wait each customer experiences, and the number of customers you’d tend to find in that queue. Knowing two of these numbers allows you to predict the third.
Because this relationship holds at a system level, regardless of what’s in the queue, we can substitute a different “customer” to understand a variety of systems, like say traffic flows at a busy intersection, or how long before kittens are adopted from a pet store.
If we exchange “customer” for “software” within a cross-functional team and (subject to a few constraints) apply the same rule to their delivery process, we find:
Work in progress = Lead time x Throughput
That is, when we measure a team’s work in progress (WIP), commonly taken as the average number of user stories they work on concurrently, we would expect to see this relationship between a story’s average lead time (how long the team spends delivering it) and the average throughput of stories that team delivers over a given time (aka their “velocity”).
One of the reasons we prefer Kanban as our delivery approach at Red Badger is for its focus on limiting WIP, allowing us to take full advantage of the power of Little’s Law. With WIP held constant, we know that by tracking story lead times we can predict a team’s velocity empirically – because we know two variables out of the three – rather than rely on estimation-based techniques such as story points used in frameworks like Scrum.
Limiting WIP also helps us focus on decreasing lead times through process efficiency and continuous improvement, which increases team throughput in the long run and gets valuable products in the hands of customers, faster.
If you’re interested in seeing the Badger way of delivery firsthand, please get in touch and we’d be happy to share more.