This is a good article. I didn't know about the #NoEstimates hashtag. It's been interesting to read. In general, I think that any discussion that informs peo

This is a good article. I didn't know about the #NoEstimates hashtag. It's been interesting to read. In general, I think that any discussion that informs people about the difficulty of making estimates where software is concerned is a good thing. I'm not delighted that the term "NoEstimates" sounds a little radical and defines itself (as the post mentioned) by what it is not. I do think that "nosql" may have harmed itself a bit that way as well, even though it really means "maybe not always sql depending on your problem", which is pretty good advice. I think the real problem, also mentioned in the article, is this: "Managers have a habit of treating developers’ back-of-the-envelope estimates as contractual deadlines, then freaking out when they’re missed. And wait, there’s more: Developers, terrified by that prospect, put more and more energy into obsessive trips down estimation rabbit-holes." This has come up in previous discussions, and it's an important point. The agile manifesto recommends we value "Customer collaboration over contract negotiation". But this blog entry about estimates identifies the problem here - casual estimates later become contractual deadlines (even if you aren't in a formal contract situation, even if it's all internal, your name next to a task and deadline = contract). So in this sense, the movement away from waterfall can simply lull developers into a casual "back of envelope" estimate that turns into "but you said you'd get it done by friday!" It's almost enough to get you to want to go back to waterfall. After all, if you're going to be held to a deadline, it helps to have a document specifying exactly what you would or wouldn't do. At least then (since specs always change), both of you are perpetually "in breach." Within this context, yeah, I can see why some people would want to just do away with estimates. Unfortunately, I can't quite see that happening. If people are trying to decide whether to fund a project (or budget for it), "how long, roughly, will this take, and how much, roughly, will it cost" is reasonable. Of course, what "this" is needs to be defined, but not to waterfall levels of detail. The key is probably a better understanding of what these estimates really mean and how they should be interpreted by an organization.