Achieving Predictable Delivery

Your story points are a mathematical lie. 

I know because I sat there—a silent, muted square on a Zoom call—watching a team of brilliant engineers burn forty-five minutes debating if a schema change was a 3 or a 5. Forty-five minutes of their lives they’ll never get back. They debated the complexity of the schema. They weighed the uncertainty of legacy code. They brought up the Definition of Done. I watched the scrum master try to drive consensus just to close the ticket and move on.

The outcome? They compromised on a 5. The work took three weeks anyway. They were wrong.

The story of the modern scrum team is one in which estimation became a proxy war for deeper dysfunction. We spend hours in refinement events trying to manufacture certainty for stakeholders who demand a date. We act like if we just slice the work thin enough and play Planning Poker long enough, the future will magically align with our Jira board. 

It never does. When the sprint inevitably blows up, the pressure lands on you. You’re left trying to help a product owner who is about to get grilled by leadership. It’s not about apologizing for a missed guess. It’s about arming your PO with the actual data they need to answer the tough questions they’re about to face. Give them the ammunition to win the conversation.

Stop the story point obsession. They are estimates. They are guesses.

Overall, we are measuring the wrong thing. We are using the wrong tools. We are burning our teams out on a ritual that produces zero actual predictability.

The statistical reality of guessing

Let’s look at the actual data. Data is that third person in the conversation who doesn’t have an ulterior motive.

I know, the purists will tell you that story points are about relative complexity, not time. I get it. But let’s be real: people still use them to forecast. They sum them up, calculate a velocity, and pretend it’s a calendar.

ActionableAgile Analytics analyzed massive datasets of empirical team delivery. They compared the numbers teams put on tickets to the actual cycle time of those tickets. 

The results are alarming. 

There is zero correlation between the number of story points assigned to a task and the actual time it takes to complete it. Zero. A 3-point story takes four days. An 8-point story takes two days. A 1-point story sits in the "In Progress" column for three weeks because a dependency blocked it. That is how work happens in a complex system.

Daniel Vacanti and Prateek Singh have spent years proving that the "size" of a ticket is one of the least important factors in determining when it will be done. They focus on the **Outside View**—using the historical performance of the system to forecast rather than the specifics of the task. Most of us default to the **Inside View**, where we obsess over the unique details, technical hurdles, and perceived complexity of a single item. 

When you rely on the Inside View, you trigger the Planning Fallacy. You imagine the happy path. You assume the staging environment will be stable. You ignore the system's reality in favor of a story.

The Outside View ignores those specifics. It asks a much simpler question: historically, how long does it take this system to finish a piece of work?

Guessing breaks down at scale. You cannot stack subjective guesses on top of other subjective guesses and expect a deterministic outcome. It is a house of cards.

The misery of the middle ground

I used to defend this practice. I sucked as a scrum master early on because I thought my job was to force consensus on these arbitrary numbers. I thought I was holding people accountable.

Looking back, I remember joining a new team and auditing their backlog to figure out why their velocity looked like a heart monitor flatlining. I discovered that almost every single story was a 3. 

Every single one. 

When you badger humans for a number long enough, they adapt. They realize that estimating high invites scrutiny from management. They realize that estimating low invites punishment when they inevitably miss the mark. So they pick the safest middle ground just to make the meeting end.

That is not agility. That is a hostage situation.

Backlog refinement is critical. Talking about the work uncovers hidden requirements and aligns the team. But that conversation is unrelated to the estimation. Have the talk. Throw away the points. Clinging to a metric that actively harms the team just because a framework suggested it a decade ago is a habit we need to break.

Predictability comes from understanding your system's capabilities rather than refining your estimates.

The probabilistic fix

If we drop story points, how do we answer the ultimate question? How do we tell the business when the work will be done?

You shift from deterministic guessing to probabilistic forecasting. You stop treating software delivery like an assembly line and start treating it like a system of flow.

You only need two non-negotiable metrics on your dashboard:

1. **Throughput:** How many things get done per unit of time.

2. **WIP (Work in Progress):** The total amount of work currently started.

Notice what is missing from that list. Size. Complexity. Hours. Points.

If you tightly control your WIP, the size of individual items stops mattering over a large enough sample size. The mathematical law of averages takes over. Your system has a natural speed limit. You just need to measure it. When something sits in "In Progress" longer than your statistical baseline—Aging WIP—that is not just a slow ticket. That is a signal worth pulling on in your next daily scrum.

You do not need years of historical data to start predicting the future. You only need 10 to 20 historical measurements of your throughput. Once you have those data points, you can run a Monte Carlo simulation.

A Monte Carlo simulation is just math. It takes your historical throughput and runs thousands of trials to see what might happen in the future. It simulates bad sprints. It simulates great sprints. The output is not a single, lying date. The output is a confidence interval.

It is for this reason that I abandoned velocity tracking entirely. Velocity is a measure of human guessing. Throughput is a measure of system reality.

I have one more lens for y’all. Evidence-Based Management (EBM) asks a question most teams never think to ask: how much of our capacity is actually going toward new value? When I run this analysis on real team data—tracking what percentage of work is bugs versus stories over successive sprints—I consistently find that Innovation Rate quietly erodes while velocity looks perfectly healthy. The team thinks they are fine. The data tells a different story. 

Forecasting when you will deliver is important. Understanding what you are actually delivering is the other half of the picture.

The executive conversation

The pushback is always the same.

"Fred, this sounds great in theory. But my boss wants a date. They want a commitment."

This is a problem. But it is a problem of communication, not mathematics. Executives understand bets more than we give them credit for. They manage risk portfolios every single day.

When you walk into a steering committee with a single date based on story points, you are giving them a false sense of security. When you walk in with a Monte Carlo forecast, you change the conversation from a commitment to a risk profile. You change your posture from a defensive order-taker to a strategic partner for the PO.

Here is the script:

"Based on our historical throughput, we ran a simulation of this backlog. We have an 85% chance of delivering these 20 items by June 1st."

Then you add the most important part:

"An 85% chance of success carries a 15% chance of failure. Period."

Let that hang in the air. Let them process the risk.

If they say a 15% risk of failure is unacceptable, you now have a real business conversation. You ask them what scope they want to cut to increase the confidence interval to 95%. You ask them what competing priorities they want to pause to lower the WIP limit.

You are no longer arguing over whether a story is a 3 or a 5. You are having a mature conversation about system capacity and business risk.

Stop guessing. Start predicting.

If you are tired of playing the delivery police, the answer isn’t better estimates. It’s better data. Monte Carlo forecasting, flow metrics, and Evidence-Based Management are three tools that—like any good Triforce—only unlock their full power when used together. Each one gives you a different angle on the same problem: your team is capable of predictable delivery, and your current measurement system is hiding that from you.

I will be exploring all of this at the **Global Scrum Gathering Vancouver** this May, including the hands-on tools and the real conversations you need to have with leadership to make the shift stick.

Your team deserves better than endless refinement arguments. Your stakeholders deserve better than fabricated commitments.

Stop estimating. Start predicting.

Hear from Fred Deichler and other incredible speakers at the Global Scrum Gathering in Vancouver from May 3-6.

Get ready to ignite your professional journey at the Global Scrum Gathering® 2026! This is your chance to join a powerhouse community of leaders in Vancouver to master the intersection of AI, automation, and agile leadership. Every session is packed with high-energy, hands-on learning—featuring insights from experts like the author of this article—to give you the practical toolkit needed to solve complex problems and drive massive organizational value. Between the deep-dive sessions and signature events like the unforgettable Monday Mingle, you’ll forge the global connections that define a career.

Register now to experience the future of agility and lead your team to new heights!

Buy my ticket