Every team I've ever worked with has the same recurring argument: "How long will this take?" Someone pulls out planning poker cards. Another person argues for t-shirt sizes. A third suggests Fibonacci. And an hour later, you've estimated 12 items and learned almost nothing useful about when they'll actually be done.
There's a better way. It involves right-sizing your work, collecting throughput data, and using Monte Carlo simulation to generate probability forecasts. It's faster, more honest, and — here's the part that surprises people — it's more accurate than expert estimation.
Why Estimation Fails
Let's be honest about what estimation actually is. When someone says "that's a 5-point story", what they're really saying is: "Based on my imperfect understanding of this requirement, my imperfect memory of past work, and my optimism bias, I think this is medium-ish." That's not data. That's a feeling with a number attached.
Research consistently shows that human estimation of knowledge work is poor. We underestimate complexity, ignore variability, and anchor to the first number we hear. Worse, we treat the estimate as a commitment, which creates pressure to hit the number rather than do good work.
Right-Sizing: Not Same-Sizing
Right-sizing is often confused with same-sizing, but they're fundamentally different. Same-sizing means breaking everything into identically-sized pieces — which is often impossible and creates artificial splits that add overhead. Right-sizing means breaking work down until each item can flow through your system in a reasonable time.
The goal isn't equal sizes. The goal is that most items are small enough to complete within your Service Level Expectation (SLE). If your SLE is "85% of items complete within 8 days", then right-sizing means breaking work down until most items fit that profile.
Practical right-sizing techniques include:
- Vertical slicing: Split features into thin end-to-end slices that each deliver some user value, rather than horizontal layers.
- The "one day of coding" heuristic: If you can't imagine completing the implementation work in roughly a day, it's probably too big.
- Cycle time analysis: Look at your historical data. Items that took more than your 85th percentile cycle time probably weren't right-sized.
How Monte Carlo Forecasting Works
Monte Carlo simulation sounds intimidating, but the core idea is beautifully simple. Here's how it works:
Step 1: Collect your historical throughput data. How many items did your team complete per day (or per week) over the past few months? Let's say you have 12 weeks of data: [5, 7, 4, 6, 8, 5, 7, 3, 6, 7, 5, 6].
Step 2: You want to know: "Can we deliver 30 items in 5 weeks?" The simulation randomly picks a throughput value from your historical data for each of the 5 weeks, adds them up, and checks if you hit 30.
Step 3: Repeat this 10,000 times. Each run picks different random combinations from your actual data. Some runs will be optimistic (lots of high-throughput weeks), some pessimistic (low-throughput weeks clustered together).
Step 4: Count how many of the 10,000 runs hit the target. If 7,200 runs completed 30 items in 5 weeks, you have a 72% confidence level.
Monte Carlo doesn't predict the future. It tells you the range of likely futures based on your actual past performance. That's far more honest than a single-point estimate.
Service Level Expectations (SLEs)
An SLE is a statement like: "85% of items will be completed within 12 days." It's not a promise — it's a data-driven expectation based on your historical performance. And it's enormously useful.
SLEs give you an early warning system. If an item has been in progress for 10 days and your 85th percentile cycle time is 12 days, that item is aging and needs attention. You don't need to wait for it to be late — you can see it becoming a problem in real time.
SLEs also give stakeholders honest expectations. Instead of "it'll be done Tuesday" (which is a guess dressed up as a commitment), you can say: "Based on our data, there's an 85% chance it will be done within 12 days of starting." That's a fundamentally more honest conversation.
Confidence Levels in Practice
The power of probabilistic forecasting is that it gives stakeholders a choice. Instead of a single date (which is almost certainly wrong), you offer a range:
- 50% confidence: We might hit March 15th. Coin flip.
- 70% confidence: March 22nd is more likely. This is where most teams should plan.
- 85% confidence: March 29th if things go typically. Use this for external commitments.
- 95% confidence: April 5th covers most scenarios. Use this for hard deadlines.
Now the stakeholder chooses their risk tolerance. "I'm comfortable with 85% confidence for March 29th." That's a conversation about risk, not a negotiation about guesses. And it's grounded in your team's actual data, not anyone's feelings.
Getting Started
You don't need fancy tools to start. Track how many items your team completes per week for six weeks. Put those numbers in a spreadsheet. Use random sampling to simulate future weeks. It's surprisingly simple once you try it.
But more importantly, start right-sizing your work. Every item that's too big injects variability into your system and makes forecasting less reliable. The better you get at breaking work into consistently-flowing pieces, the tighter your probability forecasts become.
In our Mastering Kanban interactive lab, you run Monte Carlo simulations on data you generate yourself — so you see exactly how this works in practice, not just in theory.