At first glance, story points are a product manager’s dream. After all, who wouldn’t want to have a reliable way to estimate the amount of effort needed to complete the tasks in their backlog? However, estimation isn’t easy and many teams struggle to apply story points because of challenges like miscommunication and unrealistic expectations.
That said, with agile and scrum, story points have become so ubiquitous that nearly every product team tries to use them, even in situations where they might not make sense. This isn’t to say that story points aren’t useful or that they don’t have a place in your product toolkit, you just need to use them in the right context.
To help you cut through the noise, this article assesses the reality of story points, including their promise and where they went wrong, and then offers a potential solution for what you should do instead.
Story points seek to replace the unpredictable and inaccurate unit of time with relative units of complexity. Instead of estimating how many hours a task is going to take, you give it a story point (usually in relation to the Fibonacci sequence) by assigning it to an incremental value (e.g., 1, 2, 3, 5, 8 or 13).
The thought is that you stop pretending that you can make accurate time estimations and instead focus on determining the high-level effort required to complete tasks.
In theory, story points come with some significant benefits like:
That final point may be the most important one. A task that takes two hours for a senior might take eight hours for a junior. However, two story points are just two story points, regardless of who works on the item.
The main difference is how many points a particular engineer can deliver in a week, which is significantly easier to manage than having to re-estimate every time you allocate someone else to the task.
Unfortunately, story points often don’t work in practice. You might find yourself in discussions like this:
PM: How much effort will this require?
Dev: I can do it in one day!
PM: But what about in story points?
Dev: Hmm, maybe five?
PM: How can it be five if you can do it in one day?
You can see the paradox…
Story points can also make your overall communication harder. In fast-paced environments, you need to be able to communicate with stakeholders through timelines and deadlines.
Imagine telling someone who isn’t directly involved with your team that you can deliver something in 40 story points. Suddenly, you have to find a way to translate your story points to them, adding complexity instead of removing it.
How can you plan dependencies, marketing campaigns, and other milestones based on story point values that only a few people in the company understand?
The problem with story points is that agile frameworks became so popular that people started to think they could use them for every situation. Also, this was only compounded by the fact that suddenly scrum was seen as a solution for every problem and context.
But these frameworks don’t work in every context. Teams that can reliably plan multi-month roadmaps for stable, predictable projects shouldn’t suddenly switch to sprints just to “be more agile.”
The same goes for story points. They work great in specific situations like:
However, there are situations when estimating in hours simply makes more sense — yes, even when you work in sprints.
If you need high predictability, it’s worth spending some extra time estimating more precisely. And if you already have a solid sense of how long tasks take, you don’t need to artificially translate them to story points.
First off, stop looking at story points as the best possible way to estimate work. They’re useful, but not the only tool.
If you don’t rotate team members much or work on a short time horizon, stick to good old hours. It’s the same story when working on well-understood initiatives. If a developer intuitively knows a particular task is going to take them two days, don’t force them to figure out how many story points it is.
Story points work great if you need a sense of scale for a bigger project. For example, if you have 500 tasks in your initiative backlog, spending a sprint or two to understand velocity and then estimating tasks in story points makes more sense than estimating every single task separately in hours.
As a general guide, here’s how you can decide whether to use time or relative units to estimate work:
| Approach | Benefit | When to use |
| Time (hours, days, weeks) |
|
|
| Relative units (story points, t-shirt sizing) |
|
|
You can also combine both.
I often use story points or t-shirt sizes to estimate epics or whole projects. It helps to understand the long-term horizon better. But when it comes to actual work and planning sprints and near-term timelines, I stick to hours. As imperfect as they are, they cause fewer headaches.
Story points are a useful tool, but you shouldn’t use them for every occasion. A hammer is an awesome tool, but I wouldn’t use it to paint my bedroom walls, just as I wouldn’t talk to users to validate the technical feasibility of a solution.
Story points aren’t inherently bad, but they also aren’t a universal solution. When deciding whether or not to use them, consider the following best practices:
Ultimately, the most important takeaway is that you shouldn’t force story points where they don’t fit. Use them when they provide clarity, but don’t be afraid to default to time estimates if they make more sense. It’s important to use your head and adapt your approach to the work at hand.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Daric Snyder talks about developing supportive, user-friendly healthcare software that layers on top of traditional health records systems.
Our product team transformed user research with weekly research sprints — a high-cost, high-reward alternative to continuous discovery.
Monique Piras shares how she helped redesign the feature brief and product requirements template and quarterly planning process.
Digital product leader Aditya Raju talks about the importance of meeting users in the healthcare ecosystem where they are.
Learn more →
