Back with a somewhat controversial topic. I find estimation for the sake of estimation a waste of time as teams generally focus on the wrong items in the backlog and agonize over the stuff that really doesn’t matter. What really matters is that top 15% which is truly important for the organization and your customers. That’s what you should focus on and leave the rest to discussions.
Really, Why don’t you think story points matter?
It’s not that I think they don’t matter, I think they’re an inefficient use of time for most teams. Here’s more to it:
- Teams focuses on the wrong things: I like to think that there’s 15% of your backlog that truly matters. The stuff that customer yearn for. The top 80% of revenue generation for your company. The real money making stories and the stuff that drives customer satisfaction. Different times require different needs (Ie, this software is being deprecated and we NEED to get off it) and the financial impact would be massive. Those are the type of stories andbacklog items break down, estimate and discuss. Whatever you use (points, tshirt sizing etc) I believe the conversation is more important than the number. However, many teams get stuck in the bottom 85% where things don’t really matter as much. Does it contribute to our OKRs or KPIs for the quarter? Not really but let’s agonize over it for hours. That bug? Yeah let’s solution it and go nowhere. Literally a waste of time and effort sometimes which leads to frustration and conflict on teams. Yes, yes facilitate and problem solve.
- Overhead and Time Consumption: Story point estimation often requires considerable time and effort. Meetings to discuss and argue about the number of points for each user story can be lengthy and lead to time away from actual development.
- Subjectivity and Inconsistency: Story points are an abstract measure and can mean different things to different people or even the same person at different times. This can lead to inconsistent estimates. Settling on a number is a great way to waste time sometimes.
- Focus on Velocity, not Value: Story points can shift the team’s focus to “velocity” — how many points they can complete in a sprint — rather than the actual value delivered to the user. High velocity does not necessarily mean that the most important features are being delivered. This can also lead to “velocity inflation” where naturally over time, velocity continues to increase and is misunderstood / represented as the team delivering more work.
- Difficulty in Cross-team Comparisons: Since story point estimation is subjective, it’s difficult to use it as a measure of comparison across different teams. One team’s 3-point story might be another team’s 5-point story. Yes, I understand that cross team comparison is a big no no according to a lot of agile coaches. However, the reality is we need to compare performance across the organization in high performance organizations. Being just OK isn’t good enough
- Lack of Customer Relevance: Customers and other stakeholders often do not understand the concept of story points, nor do they care about them. They are interested in the actual output and value, not an abstract estimation metric. Time to market and customer value. Process is important but not when it defeats the purpose of why we’re here.
- False Sense of Precision: Story points may give a false sense of precision or accuracy. While they are designed to account for complexity, unpredictability, and risk, they can still be off the mark. For example, a burn down is not very accurate in predicting the future. It gives a single point of time with mixed accuracy on velocity. A monte carlo simulation for software delivery is much more accurate.
My team delivers amazing and we estimate for 6 hours a week
If this works for your team and organization, that’s great. Please continue to do that. This article is here to provide an alternative to estimating everything. Try no estimation for a bit while understanding the underlying reason behind it. Maybe you’ll like it. I used to estimate everything as well too. I think it’s a non efficient use of time. Check out some alternatives below
Alternative solutions to estimating
- No Estimates: This movement suggests that teams can focus on delivering small, valuable chunks of work and measure progress by counting the completed items rather than estimating effort or complexity. The idea is to break down the work to such small pieces that they can be assumed to have roughly the same size.
- T-Shirt Sizes: This approach replaces numerical story points with sizes like XS, S, M, L, and XL. This can sometimes be less contentious and time-consuming than numerical points, as it doesn’t suggest the same level of precision.
- Monte Carlo Simulations: This statistical technique involves creating many (often thousands) of possible project schedules using probability distributions for task durations, and then analyzing the outcomes to see the most probable completion dates. What this means in English is we take your throughput for a few weeks and a specific amount of samples and run simulations on it. You then get a distribution with dates on when a project might be done. This is far more accurate than a single point in time burn down estimate. It is still not fully accurate as there are underlying assumptions made when the data changes.
- Throughput or Cycle Time: Instead of estimating work in advance, some teams simply track how much work they complete in a given period (throughput) or how long it typically takes to complete a piece of work (cycle time). This provides an empirical view of the team’s capacity. Ie, this type of ticket takes 5 days with 95% confidence. We generally tackle 15 tickets per week (3 bugs, 10 new features 2 other)
- Estimate only what matters: High priority items coming through? Yeah let’s discuss and estimate it. The rest? Nah, let’s not and move on. We need to be efficient
Conclusion
Each team and organization has different perspectives on estimation and their attitudes towards it. Some teams within the same organization can have vastly different ideas when it comes to scrum. Some think kanban and dora metrics are a waste of time while others think scrum is far too tedious. Whatever you decide, ensure that customer value and time to market is the main driving point to all of this and that it works for you. Don’t over process and deliver nothing. My perspective is that estimation for the sake of estimating is not efficient. What is more important is the conversation around the items in the backlog and how we’ll achieve an outcome that’s desirable for the organization and our customers in a timely and high quality manner.