Embracing No Estimates in Pivotal Replacement
There’s a growing movement in software development to eliminate work item estimation. It’s not just about rejecting estimates for the sake of it—it’s a well-thought-out approach that achieves the same outcomes as sophisticated estimation techniques, but with far less overhead. By focusing on breaking down work and building software rather than assigning arbitrary numbers to tasks, teams can reduce process waste and operate more efficiently.
In a truly lean sense, estimation is waste. In fact, all project management is process waste. In an ideal world, everyone on a project would have complete context loaded into their minds at all times, eliminating the need for documentation, artifacts, or process beyond the actual work itself. But, alas, we don’t live in that world—so some process is necessary. The question is: do estimates need to be part of it?
How No Estimates Works in Pivotal Replacement
In Pivotal Replacement, we’re embracing a version of no estimates where every story will be able to be assigned a single point by default. Velocity-based planning and reporting will function just as they did in Pivotal Tracker, but teams won’t need to manually estimate each story.
We may allow some flexibility—where the default is 1 point, but a story’s estimate could be adjusted within a limited range. However, the core idea of no estimates is that instead of spending time assigning values, teams should focus entirely on breaking down work into similarly sized chunks. If a story feels like it needs a larger estimate, that’s usually a signal that it can be broken down further—or at the very least, that it carries risks that need careful consideration.
The Real Value of No Estimates
This approach may seem idealistic, but the same could be said about estimation itself. In my experience, the most effective teams I’ve worked with didn’t obsess over estimates (if they estimated at all). Instead, they invested their planning and coordination time in refining work breakdown and ensuring each effort was properly scoped.
Most of the pressure I’ve ever felt to estimate thoroughly came from external forces—deadlines, stakeholder expectations, or contractual obligations—rather than an intrinsic need within the team. Instead of being a tool for continuous improvement, estimates often became a mechanism for accountability, justification, or validation. These aren’t inherently bad motivations, but there are better ways to achieve those goals without the inefficiencies of estimation.
By shifting the focus from estimating effort to defining and refining work, teams can create a more streamlined and productive development process. No estimates isn’t about avoiding responsibility—it’s about using time and energy where it matters most: building great software.
