The cry for effort estimates is the cry of those who, though they lack certainty of scope, requirements and value, seek certainty of costs, however false that certainty is.

OH old mgr explaining budget to a new mgr... Old: We use ROMs for the len of each project a year in advance New: Wait, ROMs? Old: Yes, then we calc cost as Len * std salary of assigned resources New: std? Not actual? Old: No. New: Nothing about this makes sense Old: ???

Is your refinement meeting taking too long? Are you spending most of the time in estimation discussions? Here's a tip, ask only: "can one person complete this story in about 1 day of work?" If the answer is "no", just ask the team to split the story! #NoEstimates

A #NoEstimates cornerstone

The requirements don't care about your deadlines. The code doesn't give a damn about your estimates. You can strong arm, cajole and coerce developers all you want and the software won't care. It will take as long as it takes.

"How long will it take" remains one of the laziest questions in software product development / project management.

I've yet to see a product that was improved because of estimates. I've yet to see a product that was delivered sooner because of estimates.

The #ProEstimates crowd love to point to other professions and say "See, you're just being silly. You wouldn't do X without an estimate." Ironically there's usually a mountain of evidence that X has the same or worse problems with estimation accuracy as software development.

If you’ve established a pretty high level of predictability, then estimates probably aren’t all that harmful. When you have a lot of variability, they can be devastating.

lukehohmann Broken link hijacking POC An estimate is not a commitment. Period.

Why Effort Estimation Doesn't Work: A Comprehensive Review of Late and Over Budget Projects

Why do ppl assume that estimates are necessary? I don't see the need for them myself. They're solid waterfall thinking—big upfront plans, milestones, months-long delivery cycles. Not much agility. It's deployable right now. It will be deployable w/ this new capability tomorrow.

Any management that wants you to give them predictions so they can plan is living in la-la land. That's the opposite of agility. Slapping agile-ish words on waterfall does not give you agility.

A common criticism of #NoEstimates is that the term is misleading. It's not without merit. Given its emphasis on empirical evidence over expert opinion here are just a few terms that would be more accurate: Evidence-Based Estimation Performance-Driven Planning Adaptive Planning

Guaranteed it won't be anyone with "manager" or "director" in their title.

"It's hard to predict what this dice will roll." "Well, then, you need to get better at predicting." Conventional wisdom about software development processes - that unpredictable work needs better estimates, not a more predictable way of working.

It's a well know fact that meteorology (science of weather) can scarcely forecast more than 5 days of weather ahead. Yet, software projects (which are also affected by the weather!) pretend they can plan in detail several months ahead. #noestimates

If you assigned 1 story point to every story, how much slicing would you do before you were confident you could actually complete each story in a day or so? Congratulations! You just discovered #NoEstimates. Stop trying to fit the estimate to the story. Start slicing the stories.