Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 76 posts at DZone. You can read more from them at their website. View Full User Profile

More #NoEstimates

  • submit to reddit

Quite an interesting conversation and reaction to the #NoEstimates post. Good questions too, and frankly, to some I don’t have answers. I’ll try, anyway.

Let’s start with classic project management. It tells us that in order to plan, we need to estimate cost and duration. Estimation techniques have been around for a while.

@gil_zilberfeld all estimates probabilistic based on underlying statistics of work processes. what's alternative 4 knowing cost/sched/tech?

— Glen B. Alleman (@galleman) June 19, 2014

There’s a problem with the assumption that we can “know” stuff.  We can’t know stuff about the future. Guessing, or estimating, as we call it is the current alternative. To improve, we can at most try to forecast. And we want a forecast we can trust enough to make further plans on. If confidence is important then:

@gil_zilberfeld So, get good enough at estimates to feel that confidence, make decisions accordingly. Shouldn't be a controversy. @galleman— Peter Kretzman (@PeterKretzman) June 19, 2014

Sounds easy enough…

Estimating is a skill. It takes knowledge of process and ability to deduce from experience. As with other skills, you can improve your estimations. It works well, if the work we’re doing is similar to what you did before. However, if history is different than the future, we’re in trouble. In my experience, it usually is. Variations galore.

In the projects I was involved in, there were plenty of unknowns: technology, algorithms, knowledge level, team capacity and availability, even mood. All of those can impact delivery dates, and therefore the “correctness” of estimations.

With so many “unknown unknowns” out there, what’s the chance of a plausible estimation? We can definitely estimate the “knowns”, try to improve on the “known unknowns”, but it’s impractical to improve on estimating that part.

Yet the question remains

 @adubism how do you determine cost to reach that schedule with needed capabilities? @PeterKretzman @gil_zilberfeld

— Glen B. Alleman (@galleman) June 19, 2014

Ok, wise-guy, if estimating can yield lousy results, what’s the alternative?

Agile methodologies take into account that reality is complex, and therefore involve the feedback loop in short iterations. The product owner can decide to shut down the project or continue it every cycle.

I think we should be moving in that direction at the organizational level. Instead of trying to predict everything, set short-term goals and check points. Spend small amount of money, see the result, then decide. Use the time you spent on estimating to do some work.

Improving estimates is a great example of local optimization. After all, the customer would rather have a prototype in the hand, than a plan on the tree.

And if he wants estimates? Then we will give a rough estimate, that doesn’t cost much.

I know project managers won’t like this answer. I know a younger me wouldn’t either.

But I refer you to the wise words of the Agile Manifesto, which apply to estimating, among other things:

We are uncovering better ways of developing
software by doing it and helping others do it.

There are better ways. We’ll find them.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)