Story Points answer nothing

It's 2025, more than a decade since Story Points should have been buried. But they still aren't.
Let me tell you why they're a distraction, not a solution.

The purpose of Estimation: Decisions

When Estimates come up, I always ask: "Who needs the estimate, and what decisions will be made based on them?"

Let me give you a few examples when estimation can't be answered by providing a Story Point number:

• "I need to know whether we can afford this. Can you tell me how much it costs?"
• "We need to plan for contingency in case this is late. Can you do it on time?"
• "Would it make sense to distribute the work across multiple teams to get it done faster?"
• "Is this the simplest thing we can do to reach our goal? Does it make sense to take a shortcuts?"
• "How big is the risk of failure to deliver on time, in quality by deadline?"

Did you realize that none of these questions need to be asked inside the team - and none of them relate to "Agile?"

Business-facing, not team-facing

When the only party depending on the estimate is the team, internally - why do you even estimate? There is no criticality, no risk, no dependency, no impediment. Just do it. Best you can do, as soon as you can deliver. That's enough. But - for the business, that is not enough.

None of the questions suggested above are relevant inside the team: their relevance is defined outside the team. With your stakeholders, the people who pay your bills. If they can't make a proper decision, you're alienating them, risking a communication gap that could cost you your credibility.

Stakeholders don't need to know if something is 12 or 49 Story Points. They don't care if something is a Story or an Epic. What they care is, "Do I need to adjust anything? Will I get what I need, when I need it, how I need it - at a price I can afford?"

These questions can not be answered by Story Points, unless you clearly relate Story Points back to team days and money. But if you do that - then why use them to begin with?

Estimation that doesn't drive business decisions is waste.

Customer decisions, not team decisions

What many Scrum teams and Scrum Masters fail to understand: business requires planning, too. Your sales team must give an account to your customers if they get what they signed up for. Your customers must plan their budget, and how they use their resources.

Let me give you an example: If you buy a Mobile phone, you want to know when you can use it. Customers don't accept "You get it when you get it" - they'll most likely leave the shop and take your money elsewhere. And the answer, "We still need 17 Story Points until you can use it" would immediately trigger the question, "And how long is a Story Point, exactly? Minutes, Hours, Weeks?"

Estimation that pushes uncertainty to the customer is an antipattern.

Conclusion

Before you talk about which estimation method to use, try understanding your stakeholders:

• Learn what your answer causes for them. Understand which decisions they will make with the information you provide.
• Use the estimation approach that helps you come to a common understanding with your stakeholders.
• Sometimes, "No problem, you'll have it by the end of next week" is all the information required.

When possible, skip estimation entirely - just make sure you're confident that you can live up to your promises.
But when you need to estimate: find out for whom, what they need, and give them that. And use the approach that makes you confident your answer is trustworthy.

Your job is to make the business successful, not to "do Estimation correctly."

The Castle Is Under Siege - are you the bard?

“If you focus on people being busy, you get people being busy.”

You’ve probably heard that one in some Agile training or coaching session. It sounds profound. But it’s often used in ways that are… well, wrong.

This kind of slogan gets thrown around as if it’s gospel. It’s Agile Coaching Dogma: stemming from half-understood principles and applying Goodhart’s Law in isolation.

Let’s be clear: it’s nonsense. And it misdirects.

The Castle Under Siege

Imagine a medieval castle under siege.
Enemy troops on horseback are approaching fast.
The guards are scrambling to prepare.

The defenders need bows: Everyone will be dead if the siege succeeds.

But there’s only one fletcher.

He’s already buried in work, literally stringing bows as if his life depends on it. There’s a line of guards waiting, each of them waiting for a bow. He’s clearly under pressure.

Meanwhile, his apprentice is chasing that irritating mouse which gnawed at the bread overnight.

Just at that moment, a bard arrives with a clearly urgent request:: “ My mandolin broke, and I really need you to take a look. It’s for the royal banquet tonight. The king will be very upset if there is no music!”

So what’s the real problem?

The issue here isn’t just who’s busy — it’s how busy they are - and what they’re busy with.

What we're talking about here isn’t micromanaging everyone’s calendar. It’s understanding the Critical Path and applying the Theory of Constraints.

1. You have a bottleneck on your Critical Path to success.

The fletcher is the bottleneck. No bows = no defense. No defense = everyone's dead. Preventing that situation is the mission. Everything else is a means to this end.

2. The performance of the bottleneck defines the outcome.

In any system, the bottleneck limits total performance. Here, it's the speed at which the fletcher produces bows which defines whether the castle stands or falls.

3. When the bottleneck is overburdened, stop everything that doesn’t contribute to the Critical Path.

Seriously - cancel that mandolin repair request. Forget that status report. And that retrospective can wait until the archers are equipped.

4. Everyone else's job is to support the bottleneck.

Even if they're inefficient. Two guards stringing bows badly still gives you more bows than one fletcher collapsed from being overworked.

"But they're not specialists, it's not their job description, they aren't trained ..." - you underestimate human ingenuity. They will learn. They will grow. And even if they can't do all of it, there's most certainly some steps where they can relieve your bottleneck.

5. If others are blocked, and it’s not on the Critical Path?

That’s not the bottleneck’s problem. Trying to make it the fletcher’s problem only increases the risk of failure.

Everyone has their own "highest priority. And that's exactly the problem: not knowing the Critical Path, not understanding the price your request towards the bottleneck has in the Big Picture - that's how you destroy performance and slow everything down!

Does it resonate?

In a cartoon, the issue is obvious. You see the problem.

But in real organizations?

• Workloads are hidden.
• Everything seems critical.
• Risks are opaque.
• Goals are unclear.
• And attention is given by status and urgency, not by impact.

So what happens?

• Managers ask the fletcher to put down the bows and provide a status update.
• Consultants draw the fletcher into working sesstions to map the fletching process.
• Agile Coaches pull the fletcher into a retrospective and point out that skipping the Dailies means he's not embracing Agile.

Meanwhile, the castle is about to be overrun.

The brutal truth

The fletcher doesn’t need your coaching right now. The fletcher doesn’t need an alignment workshop. The fletcher needs help!

If you’re not helping, get out of the way. And then figure out how you can help.

This is Theory of Constraints

• Identify the bottleneck.
• Utilize the bottleneck.
• Protect the bottleneck.
• Support the bottleneck.

Not everyone in your company is the fletcher. But someone is. Do you know who?

And if you’re not helping them?

You just might be the bard.