Story Points: Explicit, Honest, Predictable. Already in Use. – Daniil Bastrich← Daniil Bastrich<br>Story Points: Explicit, Honest, Predictable. Already in Use.<br>May 30, 2026<br>Every time a software estimate is inflated to absorb uncertainty and daily overhead, it stops measuring actual time and turns into a messy abstraction. Once your "hours" and "days" become a proxy for effort rather than the clock, you are already using Story Points implicitly. Dropping the self-deception and openly embracing this abstraction brings structure to your planning and helps reliably predict delivery without the guessing game.
Original human-authored content, transparent process. Verify:<br>CryptPad Writing History (File → History) GitHub Commit History
Missed deadlines, awkward excuses, and constant replanning have been haunting your team for months or even years. You might have already decided that this is just the way software development works, and there is nothing you can do about it.<br>Yet, predictable delivery is achievable, and team seniority is often not the deciding factor. If your plans collapse every week, the root cause is rarely poor execution. Usually, it comes down to a flawed estimation process.<br>In this article, I step away from abstract theory to share practical, battle-tested insights forged across multiple real projects. I will show how to make the estimation process work for short-term planning: why overestimation destroys predictability, how to forecast delivery using velocity, when and why Story Points tend to outperform time-based estimates, and how to make them actually work. Whether you are an engineering manager or a developer looking to bring more predictability to your work, the approaches and recommendations below can help you turn estimation from a guessing game into one of the most effective tools in your planning process.
Why Care About Estimates?<br>Software projects almost always come with deadlines. Whether it's satisfying user needs, meeting customer expectations, or hitting a market window - delivering late can render the entire effort meaningless. The ultimate goal is typically a release on an agreed date, which means we need predictability for developers and for the business alike. For managers, predictability often matters even more than speed: it's not about how fast you deliver, but how closely your forecast matches reality.<br>Beyond business goals, estimates heavily dictate technical decisions. When evaluating multiple options for system architecture and design, the final choice is largely driven by time constraints, not just project requirements or technical merits. Tight deadlines force us to make calculated trade-offs and discover faster workarounds. Inaccurate estimates in either direction are costly: underestimates lead to missed deadlines and needlessly sacrificed quality, while overestimates can result in overengineering and lost momentum.<br>Ultimately, the success or failure of a project hinges on the quality of planning and management decisions informed by our estimates - whether that means allocating resources, balancing priorities, planning new hires, or even self-management as a solo developer. When I help teams improve short-term planning across sprints, the biggest win is rarely "perfect accuracy" - it’s making estimates consistent enough to support better decisions week after week.
Is Precision Important?<br>When we talk about precision in software estimates, we usually mean two different things:<br>Accuracy - how closely the estimate matches the actual time spent.
Granularity - the smallest unit you use for estimates (hours, days, Story Points, etc.).
Here, I’ll focus on accuracy while exploring the minimum unit of measurement further below.<br>At first glance, it may seem that the best strategy for always having a correct estimate is to pad it as close to the upper bound as possible. For example, if I know I can implement an API in 1 day, then test and release it in 1 more day, I might add another day as a buffer for the unexpected - and then multiply the final number by 2–5 depending on the overall project state, the weather, and my mood.<br>Is such an estimate correct? In a narrow sense, yes - most of the time the task gets finished on schedule, developers appear to exceed expectations, and everyone is happy.<br>But does this approach help us make better decisions and achieve the goals of planning and forecasting? No. While heavily padded estimates might protect a team from missing deadlines, they are not suitable for analytics and bring little to no actual value. In the long run, arbitrary estimation leads to distorted data and poor decisions. To illustrate, two completely different tasks may end up with the same estimate because I happened to use different padding coefficients, or two similar tasks may have wildly different estimates because yesterday I had a rough conversation with my manager and today I decided to overestimate everything more than usual.<br>If we want estimates to be a...