# Kanban Estimation using Littles Law

I am new to Kanban, I am aware that Kanban is a flow system and estimation is optional. My stakeholders have requested the following:

1. Provide a delivery date for the remaining items (WIP)?
2. If the remaining items need to be completed within 5 weeks how many resources are needed?

I was planning to use Littles law to do the forecasting. Wondering whether my estimation and understanding are correct. If you are doing it in a different way, please advise

Historical data:

Throughput: 6 tasks/week Team size: 4 (full capacity) Work in progress: 50 (Remaining items to be delivered)

As per littles law Lead Time = WIP / Throughput

Lead Time = 50/6 = 8.3 weeks (rounded to 9 weeks)

So to answer question 1, With 4 resources at a throughput rate of 6 tasks/week, I would need 9 weeks to complete 50 tasks. Is this correct?

Let's move to question 2, in order to deliver the WIP within 5 weeks. I am using the below formula

9 weeks to deliver 50 WIP requires 4 resources 5 weeks to deliver 50 wip requires how many resources = 9/4 x 5 = 12 resources

Is this correct ?

• Based on comments, you're actually trying to determine total schedule run-time based on projected (not actual) throughput. Little's Law doesn't intrinsically say anything about this; it's more applicable to determining response or wait times for stable systems based on average arrival rates. In your case, you're really just trying to estimate a schedule based on throughput for a fixed queue. I'm not sure why average lead time would be used for this; predicted cycle time or Takt time would most likely give you a more accurate answer, after allowing for a bit of process overhead. Jan 22, 2020 at 1:13
• While the questions (and frameworks) are different, my answer for agile release planning in Scrum is probably applicable here as well. Jan 22, 2020 at 1:19

## TL;DR

I'm not going to address your math directly, because it's a solution for Y in an X/Y problem. Specifically, how long it takes to complete your current backlog should be a function of your current lead and cycle times, not an invitation to resize your queues or attempt to crash the project by adding additional resources.

What you really ought to do is determine whether your current process throughput can empty the process queue in the run-time remaining for the project. There are many ways to do that, and I'll demonstrate a few of them below.

## Analysis and Recommendations

Your product backlog shouldn't be counted as "WIP." Work items remaining in your Product Backlog are backlog items. They don't become work-in-progress (WIP) items until someone begins actively working on them.

Your current cycle and lead times will generally provide a more accurate forecast than trying to retcon your queue sizes, available resources, or WIP limits at this late stage. Changing your process invalidates or distorts the historical averages of your metrics, and will therefore result in a much lower confidence interval for any predictions you make.

Additionally, adding resources to compress the project's schedule will rarely increase throughput at this late stage (see Brooks' Law). I'd also think your current cycle and lead times will be more accurate than trying to retcon your queue sizes.

Assuming that the size of your backlog items are all within the same order of magnitude, and that the work remaining fits the same process that prior work has used, then you could simply multiply your average lead time for backlog items to the number of backlog items remaining. For example:

``````days_remaining     = 30
backlog_items      = 50

# lead time is often a product of queue delay and system throughput
#=> 250

# determine if all remaining work can fit into available runtime
#=> false
``````

Lead time should be accounting for queue delays and implicit WIP limits already, so the math is pretty easy if you have historical values. However, if you don't have a good handle on your lead time, you could look at your cycle time and WIP limits instead. For example:

``````backlog_items      = 50
days_remaining     = 25
cycle_time_in_days = 1.2
wip_limit          = 6

(backlog_items * cycle_time_in_days) / wip_limit
#=> 10

# determine if all remaining work can fit into available runtime
((backlog_items * cycle_time_in_days) / wip_limit) <= days_remaining
#=> true
``````

You might also look at Takt time or cumulative flow rates, but in all cases you are really just trying to determine whether your existing process throughput can empty the Product Backlog queue within the runtime remaining. You might apply Little's Law to a stable system that has no finite time constraint, but in my opinion the theorem doesn't really help you answer the underlying capacity/scheduling question you actually have.

### Don't Abandon Empirical Data

As a rule of thumb, you should focus on using empirical values from your existing process to seek a sufficient confidence interval, and then either:

1. trim scope to fit the schedule/budget, or
2. extend the schedule/budget to fit the scope.

Re-engineering your team's process at this stage, or adding resources late in the schedule, is a project management anti-pattern. Last-minute changes probably won't provide you enough runway to apply empirical controls to your process, and appeals to mathematics will generally result in either false confidence or ersatz precision. That way lies sadness and despair.

Agile frameworks rely on empirical data and long-term averages, so that "tomorrow's weather" is a relatively high-confidence forecast based on observable (and consistently measured) results. Invalidating historical data turns reliable forecasts into arbitrary management targets. Don't do that!

• @Sam To answer your comment, in the unlikely event that you have correctly captured 100% of your requirements up front, `500 stories / 6 stories per week = 84 weeks` to complete the entire backlog. In Kanban, you continuously refine your estimates based on empirical values. If you have no empirical values, then you start with a guesstimate and then refine it over time. Kanban is about developing predictable cadences, not guaranteeing specific outcomes based on math. Jan 21, 2020 at 23:44
• Thanks for the detailed explanation Todd. I agree that adding resource at late of the project will have impacts and its a anti pattern However in Kanban for a new project how can we do the capactiy planning and estimation assuming we have 500 userstories to be delivered and teams throughput based on similar project is 6 tasks per week with 4 resources. What would be the formula to derive the required resources and timeline in kanban ? Lets assume if management has a delivery target of 500 userstories to be done in 50 weeks. How to derive the capacity and timeline required ?
– Sam
Jan 21, 2020 at 23:47
• @Sam I think your problem here is that you're conflating management targets with capacity-based estimates. `500 / 50 / 6 = 2 teams`, assuming both teams have similar capacity and all stories are roughly the same size. But that's a math problem divorced from reality; it's still wrong because that provides zero slack and glosses over a lot of practicalities. It's also a faulty premise, because the chances of having exactly the right number of user stories at precisely the right level of granularity at project initiation are roughly `zip / zilch * squat`. Kanban is about iterative improvement Jan 22, 2020 at 0:54
• towards a goal or cadence, not a way of accurately planning capacity ab initio, especially outside of manufacturing. Pragmatically, if you assume all teams have roughly the same capacity, I'd make an initial guesstimate of three teams, and then add or trim resources as needed until the cadence stablizes at a rate that will have at least an 80% confidence interval of meeting the end-state target. But that's actually a very different question than the one you asked, and should really be asked separately. Jan 22, 2020 at 0:57
• @Sam FWIW, I'm not saying that team sizing, capacity planning, or queue management aren't valuable activities. I'm just suggesting that Little's Law isn't the right first-order tool to solve this particular capacity planning problem. I could be wrong; perhaps someone else has a different idea. Pragmatically, there are easier approaches to right-sizing resources based on empirical feedback, so I'll probably just leave it there. Jan 22, 2020 at 1:35