Back to all Articles

Should We Stop Estimating?

Stacey Ackerman

In 2012, Woody Zuill, a programmer from Southern California, tweeted, “#NoEstimates--I’ve added a bit more fuel to the fire.”

Zuill based this off of a software project he was working on. Instead of giving his boss an upfront estimate, he negotiated getting the highest priority feature into production in a sprint and then giving an estimate after. The team did this in two weeks and the boss no longer asked for upfront estimates.

Since this time, the #NoEstimates hashtag has created a lot of controversy in the agile community. We decided to take the discussion to our Agile Mentors Community to get a variety of perspectives around the question, “Should we stop estimating?”

1. Too much time spent estimating is waste.

The general consensus was that whether you call them hours, story points, T-shirts sizes, or the time it takes to bathe a toy poodle vs. a Saint Bernard, too often estimates become just a number—with no real significance or meaning. In Lean terms—waste.

One AMC member stated that he really likes Woody’s assertion (in this video) that getting really really good about delivering small bits of value soon and often, may, in fact, lessen our reliance on long-term estimates and deadlines. Wouldn’t that be a wonderful situation to be in?

Someone else reminded us that the first thing written in the Agile Manifesto is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

That person went on to say that we do not accomplish that by placing arbitrary dates on delivery of something that we don’t even know what it will look like at the end.

2. Leaders will always need to know timelines.

While #NoEstimates seems great from the software developer’s point-of-view, the problem, however, is what to do with sales, project managers, product managers and C-Level people who want to know when and how much.

One agile coach said her teams tried to only estimate stories they were working on or had refined—anything else in the backlog was left without estimates. This became problematic, however, when management asked for metrics because the teams couldn’t provide them without at least some level of estimation.

Mike Cohn, who is known worldwide for his book, Agile Estimating & Planning, jumped in on this discussion.

“I wrote years ago that management asks for estimates in too many cases. That’s true. But to say that estimates should go away and that they’re useless is either massively naive or largely intended as clickbait. I don’t recall which, but one of [the proponents] (probably Woody) flat out admitted that it’s really about fewer estimates and not no estimates,” Mike says.

One member who follows the #NoEstimates movement closely, said that the underlying agenda of the movement is to get us to change our minds about the value we place on estimates.

That member said he interprets the movement as meaning the following:

Stop automatically associating an estimate with a commitment. Stop allowing estimates to drive hard delivery dates. Start considering estimates as a level of confidence about delivery. Start understanding that estimates are guesses about things that are going to happen in the future that we can’t entirely predict.

3. Estimate in a new way.

There are many ways to estimate—from the traditional approach of estimating an entire project in detail, to high-level estimating of only what’s in front of us. Our members shared a few different ways in which their teams have decided to tackle estimation.

On member described how a team they worked with broke stories down into pieces that could be completed in two-to-four days and estimated each piece of work as two points. Because everything was so small, they no longer needed to estimate.

Another member explained that they estimate by using story points. They estimate at a high-level about two sprints ahead of what the team is currently working on t. During sprint planning, they then break work into tasks and estimate those using time. They find that the estimates are more accurate since the work is very small and right in front of them.

Yet another member described how they use T-Shirt sizing to balance long-term planning needs with the realities of software development The team usually has a broad sense of the size of a single feature, and that can be used to extrapolate the expected size and cost into a bucket—is it more than $250k and less than $500k?

Another member told the group about his team’s experience doing some Product Increment (PI) planning using Scaled Agile. During that two-day meeting, the team engaged stakeholders, finding out what their needs were, addressing what could and could not be built and coming up with an effective solution that would meet their needs. The team then did some estimating and told the stakeholders how much of that vision could reliably be delivered in the next 10 weeks. This collaborative design process saved the company hundreds of thousands of dollars of wasted effort, but it didn’t stop there—the stakeholders got feedback every so often during that 10-week period so they could evaluate whether what the team was delivering would meet their objectives.

One last member explained that they find Planning Poker® and velocity extraordinarily useful for Scrum teams, especially those growing into maturity, and would never EVER advocate abandoning those practices. “I believe T-shirt sizing larger things is much better than the waterfall days of monolithic exhaustive estimates,” the AMC member said.

4. Estimation is valuable for the organization.

One AMC member pointed out how estimates are valuable to an organization and contemplated just how the

No Estimates movement would do without the following:

*Estimates are useful to the team to demonstrate if a story is small enough to tackle. The fast and simple estimation of relative complexity helps reveal this without as much emotion or feeling getting involved.

*Estimates are useful for a team to work out how much to bring into a sprint and to avoid overplanning.

*Estimates can be useful in a team where roles are split to identify areas of difference and bring in different perspectives.

*Estimates help prioritize the product backlog. Without sizing, it’s impossible for a product owner or stakeholder to know how much work “costs” and if they really want that feature.

*Estimates feed velocity, which is a useful tool not just for the team, but for transparency to the wider organization.

There were many perspectives from the AMC on the subject of estimation, along with a wide range of ideas on practical estimation techniques. Overall, members agreed that some level of estimation is needed and that abandoning estimation altogether, while it sounds great in theory, is unrealistic in practice.

To read more about the #NoEstimates movement and many more agile hot topics, consider joining the Agile Mentors Community at https://www.agilementors.com.

Do you have the advantage of being an Agile Mentor?

Network with more than 2,330 members and get exclusive insights on the agile strategies that are working today. Get direct help from Mike in monthly video Q&A sessions. Be mentored by agile experts and share your experience to mentor others, only when you join the Agile Mentors Community.