.svg)
We came across an interesting Reddit post some time ago: "Story points are driving our team crazy," the title reads. "What estimation method actually works for you?"
The author goes on: "Our agile team is struggling hard with story points. Half of the team thinks they are useless. The other half can't let go of them. We are spending more time arguing about whether something is a five or an eight than actually building features."
As a product manager or engineering manager, you've probably experienced some version of this. The endless debates and planning poker sessions that take longer than expected, plus the feeling that you're all participating in an elaborate charade that helps no one.
When most teams face this, they blame the tool. Should we switch to ideal days? T-shirt sizing? No estimates at all?
But after speaking with Sameer Zaman, an agile coach who's guided dozens of agile teams, he shared something profound: Story points aren't the problem. They're just the symptom of communication issues.
In this article, we'll share practical tips from Sameer such as how to make storypoints less arbitrary, the 15-minutes rule that stops estimation debates, why you shouldn not use estimation as performance metrics and so much more.
Prefer to watch the conversation? it's on YouTube.
What Are Story Points?
Story points are a way for your team to express the relative complexity and effort of work. They are not a precise measure of time or productivity.
What they’re meant to do is help you compare one piece of work to another, plan sprints based on historical capacity, and talk about complexity, risk, and uncertainty. They are not to be used for comparing teams or ranking individual or team performance.
When you lose sight of that, story points feel less valuable because you’re using them for the wrong reasons.
Why Do Story Points Feel So Arbitrary?
Story points feel arbitrary when you don't close the loop between "what we thought" and "what actually happened."
Your team sits in a room (or a Zoom), looks at a backend API integration, and someone says, "That's a five." Why? Because it feels like a five? Because the last API thing was a five? Because five is a nice middle-of-the-road number that won't make anyone too uncomfortable?
Sameer doesn't sugarcoat this: "At the beginning, it's an arbitrary. There is a significant degree of sort of arbitrariness to it because you're literally trying to pick something out of the ether."
And this is where most teams stay. They set initial estimates, sprint after sprint, and never verify whether those guesses translated to reality. The five-point story takes three days. The eight-point story takes two. The three-point story somehow balloons into a week-long work involving three other teams and a production incident.
The estimates stay arbitrary because most teams never do the work to make them not arbitrary. You forget that you can transform guesswork into knowledge through a deliberate verification cycle.
That's what needs to change. And it starts with building a system that catches problems before they derail your sprints, then turns your estimation into actual knowledge, then protects that knowledge from being weaponised. Here's how.
Part 1: Stop Long Estimation Debates with the 15-Minute Rule
Before you can fix estimation, you need to stop wasting hours on stories that aren't ready to be estimated in the first place. You can stop this using the 15-minute rule.
What Is the 15-Minute Rule?
The 15-minute rule is a team-agreed timebox for estimation discussions. If you hit the limit and still can't agree, the story isn't ready. It goes back to the stakeholder for clarification.
We already know that one major thing that derails many sprint planning sessions is long debates around story points.
Someone brings up a story, questions start flying and different people have different interpretations. Thirty minutes later, you're still talking. Sameer's solution is simple and practical: Timebox the debate.
"If the discussion around a story went longer than—on one team it was 12 minutes, on another team it was 15 minutes—if we're sitting there for 15 minutes and there's still back and forth going on and everyone's got questions, concerns, problems with it, that's when we decide that's our cutoff."
The story goes back to the product owner. It's not ready to be estimated because the team doesn't have enough clarity to estimate it.
But the 15 minutes aren't wasted. During that time, the team is "capturing the points of contention, the questions, the concerns, things that need further clarification."
This documentation becomes the product owner's checklist for going back to the stakeholders. Or it becomes the agenda for bringing the stakeholder into the next refinement session to explain the work directly.
This time limit isn't imposed by the scrum master or product owner. It's a team decision. One team landed on 12 minutes. Another chose 15. Another went with 20. The specific number doesn't matter. What matters is that the team agreed on it together, during their norming process, based on their own experience of what works for them.
This rule does something critical: it prevents your team from burning hours on stories that lack clarity. But catching unclear stories is just the first step. Once you have stories worth estimating, you need to turn those estimates into actual knowledge. That's where running report card comes in.
Part 2: Build Knowledge with the Running Report Card
You’ve addressed the immediate issues. Now it’s time to turn assumptions into informed decisions.
How Do You Make Story Points Less Random?
You make story points less random by treating them as hypotheses, then checking them against reality every sprint. Sameer maintains what he calls a "running report card" for every story. It works in three stages.
Stage 1: Sprint Planning Check-In – "Has Anything Changed?"
When a story gets pulled into a sprint, the team doesn't just accept the estimate from two weeks ago. They ask: "Since we last looked at this, has anything changed? Do we have new information? New capabilities? Lost team members?"
The estimate isn't sacred. It's a hypothesis that's validated or updated based on current information.
Stage 2: During the Sprint – "Is This Matching Our Expectation?"
Throughout standups and one-on-ones, watch what's actually happening. If the developer who picked up that five-point story says, "Yeah, everything's running smoothly, exactly as we expected," you're building evidence that five points means what you think it means.
Stage 3: After the Sprint – "What Did This Story Really Turn Out to Be?"
At the next sprint planning, before diving into new work, review what was just completed:
"So this API integration story—we said it was five points. Team member XYZ, you worked on it. Did you encounter any surprises, any issues?"
Sometimes the answer is: "Nope, went exactly as expected."
Great. Now you know. That's what a five-point story actually looks like.
But sometimes the answer is: "Oh man, there was a heck of a lot more going on. Once we peeled back the layers of the onion, there was way more integration than we thought. We had reliability issues. We had dependencies on other teams we didn't even know about."
Okay. So that wasn't a five-point story. That was an eight.
And sometimes you may get a different answer:
"Honestly? We totally overestimated that. It was a cakewalk. I was able to reuse code from another story. Team member ABC jumped in because they had free cycles. We knocked it out in no time. That was really a two-point story."
This running report card, maintained sprint after sprint, is how you transform "picking something out of the ether" into "using the team's own history of work and delivery to establish and benchmark future work."
Three sprints in, when you're estimating another API integration, you're not guessing anymore. You're comparing: Is this more complex than the one we did in sprint 2? Less complex? About the same?
That's relative sizing. And it only works if you actually close the loop.
Now you have a system: catch unclear stories before they waste your time, then build knowledge from the stories you do complete. But here's where most teams fail. They build this internal system, then let it get destroyed by external pressure. That's the third piece you need to protect.
Part 3: Protect Your System from Performance Metrics
You've built a functioning estimation system. Now you need to protect it from external people who don't have full context into your team dynamics.
Should You Use Story Points for Performance Metrics?
You should not use story points as performance metrics. When story points are used as performance metrics instead of planning tools, your team start gaming them, and the numbers lose their meaning.
Sameer shared a story that illustrates exactly how this breakdown happens.
His team was doing well. Really well. They were delivering consistently. The program sponsor "fiercely protected his squad, believed in their ability to deliver, and do great work, and espoused as such to all of his audience, his stakeholders at his level and higher. This is a high-performance team. They deliver phenomenally consistently."
During a sprint zero session with an external agile coach, someone mentioned, "This is a high-performing team. We deliver 55 points of work every sprint."
The coach's response: "That's not a high-performing team. High performing teams deliver 70, 75, 80 points of work. You guys only deliver 50."
Two senior developers immediately hung up from the call. Later, one of them said:
"Okay, they don't think our 55 points are high-performing. Guess what, all our eight-point stories are now 13 points. So look at that, there you go. We hit our point metric."
This is what happens when you turn story points into a performance target. Goodhart's Law comes to mind: When a measure becomes a target, it ceases to be a good measure.
What Is Sandbagging with Story Points?
Sandbagging is when teams inflate story points to look "high performing" while actual output stays the same.
If story points determine whether your team is "high performing," then the rational response is to inflate estimates. Make everything an eight. Hell, make everything a thirteen. Watch your velocity soar while your actual output stays exactly the same.
Story points were meant to help you plan, understand capacity and make sustainable commitments. Using them to compare teams or measure productivity destroys all of that.
As Sameer puts it: "Without context, they will be, can and will be misinterpreted."
An external stakeholder sees 50 points in one sprint, 70 in the next, then 25. They conclude: performance is declining.
But they don't know that:
- The 25-point sprint included three production incidents
- Two team members were out sick
- The stories were more complex than initially estimated
- There were unexpected dependencies on teams in other time zones
Story points are "unique to each team." A five-point story for your team might be a two-point story for another team with more experience in that domain, or an eight-point story for a team working in an unfamiliar stack.
Comparing velocities across teams is like comparing finishing times between a marathon and a triathlon. Without context, the numbers lose their meaning.
Should You Share Story Point Velocity with Stakeholders?
No. Keep velocity and story points as internal planning tools. Stakeholders should see progress against outcomes, not point totals.
After the incident with the external coach, Sameer's team made a decision. They had been including velocity metrics in their sprint demos: moving average, burn down, points delivered this sprint versus last sprint, backlog health. All shared in a PowerPoint deck sent to stakeholders.
They decided to stop. They realized that "their metrics are unique to them and that, without context, they will be, can and will be misinterpreted."
They removed all velocity information from external presentations. Instead, they told stakeholders:
"If anyone is looking for any sort of performance information with regard to the team, please reach out to me, Product Owner A, Product Owner B, or Program Manager. We're happy to give you any information you need about the team's overall performance. But we will no longer be sharing this."
Story points are an internal tool for the team to understand their own capacity. When external stakeholders use them to judge performance, it creates perverse incentives and destroys morale.
What Metrics Do Stakeholders Actually Need?
Stakeholders don't need to see story points. They need to see: commitments, delivery against those commitments, and progress toward outcomes.
You might be wondering, "Okay, but if stakeholders can't see velocity, what should they see?"
Sameer's answer: Benchmark the team against what they committed to.
His teams use PI (Planning Increment) planning. At the start of each quarter, they lay out a roadmap:
- Our top three to five objectives for this quarter
- Stretch objectives if we can go further
- The epics that support those objectives
- Stories within those epics, mapped across six sprints
"Here's what we're committing to for Q2. Here's the work by sprint. That is what would be used as a benchmark and a report card on the team's ability to deliver."
This isn't a set-it-and-forget-it document. Every sprint planning session, the team revisits the roadmap. Every sprint demo, they show stakeholders how the work they just completed fits and rolls up into the higher-level objectives that we have defined.
This gives stakeholders what they actually need: a higher program level view that assists in giving the macro level trends that the team is following and how it translates into the overall delivery to what the team committed to, and whether or not the stakeholder is going to get what they need at the end of the period.
They don't need to watch the grass grow every day. They need to know: Are we getting the value we expected? Is the team delivering what they committed to?
So now you have the full system: catch unclear stories before they waste time, build knowledge from completed work, and protect that knowledge from being weaponized as performance metrics. But what happens when this system still doesn't work? Usually, it's because the underlying communication has already broken down. Here's what that looks like.
Why Story Points Still Fail (Even With a Good System)
Even with the 15-minute rule, the running report card, and proper stakeholder boundaries, story points can still fail. That's because estimation is fundamentally a social activity. If your team can't communicate effectively, no system will work for you. It inevitably leads to some team members thinking that story points are useless.
Why Do Developers Say "Story Points Are Useless"?
Developers usually say "story points are useless" when their expertise isn't respected, estimates are overridden, or points are misused.
Let's talk about what's really happening when half your team thinks story points are garbage.
"The mistrust that a dev team member would have in the story points would usually stem from a place where they perhaps feel that their input, their expertise, and insight are not valued," Sameer said.
Imagine you're a senior developer. You look at a backend API integration. You've built dozens of these. You know the gotchas, the edge cases, the places where complexity hides. You say: "This is an eight-point story."
The product owner responds: "I know you said this is an eight-point story, but I really need this to be a five-point story."
What just happened?
Your expertise was dismissed. Your estimate was treated as negotiable. The message is clear: your judgment doesn't matter as much as hitting some target number.
After a few rounds of this, you stop caring about story points. Why invest energy in thoughtful estimation if your estimates get overridden anyway?
Sameer's response as a scrum master would be to create space for a real conversation:
"What are you trying to achieve by telling someone this is a five-point story instead of an eight-point story? Jonathan, our senior-level dev, says this is an eight-point story. Why are you not trusting what he is saying?"
Often, the product owner's concern is about reporting to stakeholders. They promised something by a certain date. They need to show progress. They think making it a five-point story helps somehow.
The solution isn't to manipulate the estimate. It is to have a different conversation with the stakeholder about what they actually need and when they can realistically get it.
What Do Social Dynamics Have to Do with Estimation?
Estimation is a social activity. If your team can't talk honestly and openly, no estimation method will work for you.
Here's something Sameer said that's profound: "Software development, any work, but software development especially, is a very social sort of undertaking and endeavour."
Yes, you can "go off into a silo and go do the work," but what you end up producing could be very different from what was requested by the stakeholder.
Estimation is no different. It requires the same social interaction, discussion, and mutual respect that effective software development demands. The teams that make story points work aren't using some secret technique. They're having better conversations.
They're:
- Creating dedicated forums for estimation discussions (90-minute to 3-hour timeboxes for backlog grooming)
- Involving developers in establishing what estimates mean
- Respecting expertise or having genuine conversations about concerns
- Continuously verifying estimates against actual delivery
- Documenting decisions so knowledge persists
- Giving teams a voice in retrospectives to surface frustrations before they metastasize
At the core of everything is constant dialogue with the team. It's not really about the tools, but it's about the dialogue happening in the team.
What's the Real Problem When Story Points Don't Work?
The problem usually isn't the estimation technique. It's trust, involvement, and the lack of a shared definition of what points mean.
When people say story points aren't working, the knee-jerk reaction is to focus on the estimation technique itself.
Sameer suggests going upstream: "I would want to go one or two levels further upstream and be like, okay, what is driving the discussion and the work to the point where there's a disconnect in the story points value between team members?"
Usually, it traces back to:
- Developers not involved in defining what estimates mean
- Estimates are being overridden without explanation
- Story points are being used as performance metrics
- No follow-through on verifying estimates against actual delivery
- Lack of psychological safety to voice concerns
These are communication, organizational, and trust problems. Story points are just where they become visible.
How Quely Solves Communication Issues in Estimation
The whole conversation kept coming back to one thing: estimation only works when your team has context and can actually have meaningful dialogue. But that's hard when everything's scattered across Slack threads, Jira comments, and Google Docs.
That's why we built Quely. Pull in your Jira items and get one workspace per task where all conversations, docs, and decisions live. Our AI analyzes each task and asks follow-up questions to uncover those blind spots that usually derail estimation sessions. You can run async estimation with story points, see who's actually available with capacity planning, and switch to a real meeting if you need to, all in the same place.
We're ensuring conversations happen in one place so you can align and execute faster.
Check out our interactive product tour to learn more.
Common Questions About Story Points
Are Story Points Still Worth Using?
Yes—if you use them as a planning tool, keep them internal, and regularly calibrate against actual delivery. They help teams forecast capacity and plan sustainable sprints. But the moment you use them as performance metrics or compare them across teams, they become toxic and lose all meaning.
How Do You Explain Story Points to Stakeholders?
Don't show them the points. Show them what matters: features shipped, objectives met, and roadmap progress. If they ask about story points specifically, explain they're relative (a five is more complex than a three), team-specific (your five might be another team's two), and used for internal planning, not to judge performance.
What Should We Do If Estimation Debates Drag On?
Timebox it. Agree on a limit (12-20 minutes), capture all the questions and concerns, then stop. If you can't estimate it in that time, the story isn't ready. Send it back for clarification.
How Do We Make Story Points Less Arbitrary?
Close the loop every sprint. At planning, review 2-3 completed stories and ask: "Did this match our expectation?" Adjust your understanding of what each point value means based on reality. After 3-4 sprints of this, you'll have real reference points instead of guesses.
Should We Switch to T-Shirt Sizing or No Estimates?
Switching methods won't fix a communication problem. T-shirt sizing and #NoEstimates need the same things story points need: clarity, trust, and verification. Before you switch, ask: Are developers defining what estimates mean? Are we checking guesses against reality? Are we using this for planning or performance theater? Fix those first.
How Do We Stop Stakeholders From Comparing Team Velocities?
Remove velocity from external presentations entirely. Explain why cross-team comparisons are meaningless (different scales, different domains, creates sandbagging), then show what actually matters: delivery against commitments. Give stakeholders the macro view, like roadmap health, feature completion, without the internal planning numbers they'll misinterpret.
What If Our Product Owner Keeps Negotiating Estimates Down?
Surface the dynamic directly: "What are you trying to achieve by making this a five instead of an eight?" Usually, they're feeling some pressure from a stakeholder. The solution is to have a different conversation with stakeholders about realistic timelines. When you override developer estimates, you're telling them their expertise doesn't matter. That's how you kill engagement.
How Long Does It Take for Story Points to Stop Feeling Arbitrary?
Three to four sprints with disciplined feedback loops. Review completed work, capture what surprised you, and adjust your mental model. That's enough history to have real reference points. But if you skip the loop and never verify estimates against reality, they'll stay arbitrary forever.