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."