The reality of story points

Originally written at pooyan.info Who is the author? Check out my profile on LinkedIn. What is 1 story point? I bet if you ask 10 people, you'll get 10 different answers. Yet, we "estimate" and measure based on that. What is the origin of story points? Story points originated from Extreme Programming (XP) as a way to estimate effort without tying it directly to time. The idea was to move away from inaccurate time-based estimates and instead use a relative sizing approach. They were inspired by techniques like Wideband Delphi (derived fromDelphi method as a forecasting tool) and Planning Poker, where teams collectively assign values based on the estimated complexity, known risks, and guesstimated effort. What problem did it want to solve? Traditional time-based estimation often led to missed deadlines and unrealistic commitments. Story points aimed to solve this by: Encouraging relative estimation over absolute time-based guesses. Reducing pressure on developers to commit to unrealistic timelines. Allowing teams to adjust based on historical velocity rather than gut feeling. What are the common alternatives? While story points are widely used, some teams prefer: Time-based estimation: Estimating directly in hours or days. No estimates: Delivering work in small, consistent chunks and tracking throughput instead. T-shirt sizing: Categorizing work into Small, Medium, Large, and XL sizes. Why none work? Every estimation method has flaws: Time-based estimation: It is almost impossible to predict everything in creative domains where things change quite fast. No estimates: It works well for mature teams but can be hard to adopt in traditional orgs. T-shirt sizing: It’s still a form of estimation but lacks granularity. Ultimately, estimation is always imperfect because software development involves uncertainty and variability. When things cannot be estimated properly, how can developers commit to what they promise as when they are "estimated"? If estimation is not important and failing them is okay, they why do we need to pressure? Is it okay to train our team to estimate to fail? Will that become a part of the culture? If it is not okay to fail, then, these estimates will be used as a tool to pressure and point at the most important assets of modern companies when timelines are not met. What to do instead? Instead of obsessing over story points or alternative estimation methods, teams should focus on: Delivering work in small, manageable increments. Tracking actual throughput over time. Communicating openly about uncertainties and risks. Using historical data to have an idea about the future and be open to continuously keep their plans updated. Removing the "update to me" management style, and build teams based on trust. The goal isn't perfect estimation—it's delivering value consistently and somehow predictably. Remember, quantifying uncertainty doesn't eliminate it. It just gives the illusion of control. The main values rely on things that are qualitative, and cannot be easily measured. If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn. Copyright & Disclaimer All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article. While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site. The contents of this article should not be construed as legal advice. Opinions are my own and not the views of my employer. English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication. Links or references to other websites, including the use of information from 3rd-parties, are provided for the ben

Apr 5, 2025 - 05:32

Originally written at pooyan.info
Who is the author? Check out my profile on LinkedIn.

What is 1 story point?

I bet if you ask 10 people, you'll get 10 different answers.

Yet, we "estimate" and measure based on that.

What is the origin of story points?

Story points originated from Extreme Programming (XP) as a way to estimate effort without tying it directly to time. The idea was to move away from inaccurate time-based estimates and instead use a relative sizing approach.

They were inspired by techniques like Wideband Delphi (derived fromDelphi method as a forecasting tool) and Planning Poker, where teams collectively assign values based on the estimated complexity, known risks, and guesstimated effort.

What problem did it want to solve?

Traditional time-based estimation often led to missed deadlines and unrealistic commitments. Story points aimed to solve this by:

Encouraging relative estimation over absolute time-based guesses.
Reducing pressure on developers to commit to unrealistic timelines.
Allowing teams to adjust based on historical velocity rather than gut feeling.

What are the common alternatives?

While story points are widely used, some teams prefer:

Time-based estimation: Estimating directly in hours or days.
No estimates: Delivering work in small, consistent chunks and tracking throughput instead.
T-shirt sizing: Categorizing work into Small, Medium, Large, and XL sizes.

Why none work?

Every estimation method has flaws:

Time-based estimation: It is almost impossible to predict everything in creative domains where things change quite fast.
No estimates: It works well for mature teams but can be hard to adopt in traditional orgs.
T-shirt sizing: It’s still a form of estimation but lacks granularity.

Ultimately, estimation is always imperfect because software development involves uncertainty and variability.

When things cannot be estimated properly, how can developers commit to what they promise as when they are "estimated"? If estimation is not important and failing them is okay, they why do we need to pressure? Is it okay to train our team to estimate to fail? Will that become a part of the culture?

If it is not okay to fail, then, these estimates will be used as a tool to pressure and point at the most important assets of modern companies when timelines are not met.

What to do instead?

Instead of obsessing over story points or alternative estimation methods, teams should focus on:

Delivering work in small, manageable increments.
Tracking actual throughput over time.
Communicating openly about uncertainties and risks.
Using historical data to have an idea about the future and be open to continuously keep their plans updated.
Removing the "update to me" management style, and build teams based on trust.

The goal isn't perfect estimation—it's delivering value consistently and somehow predictably.

Remember, quantifying uncertainty doesn't eliminate it. It just gives the illusion of control. The main values rely on things that are qualitative, and cannot be easily measured.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.