There's lots of misinformation going around again in the #NoEstimates community
- We can't estimate things we've never done before - this is simply not true. There is not much that hasn't been done before in some form. If you truly haven't done the work before, you're probably not the right person to be estimating for those wanting to pay you.
- Estimates are guesses, because we don't know that the future is - this is a fundamental error, either of commision or omission, on how estimates are made. Estimates are informed by the underlying probability and statistics of the processes or work of the project. If you're guessing you're not estimating, you're guessing. Go toss a coin.
- Just deliver often in small chunk and we won't need to estimate - this of course ignores the need to produce an Estimate To Complete and an Estimate At Completion.
- Estimates are a waste, we should be coding to generate value for the customer - the customer has a fiduciary need to know how much it will cost to get that value and when that value will be delivered. This is core business. If there is no need to know estimated cost and schedule, the project is likely a de minimis effort, or the customer has enough money to burn to not care about how much and when. As well Value cannot be determined without knowing the cost to produce that value. This is core to all business decision making.
Return on Investment is ROI = (Value - Cost)/Cost. Both Value and Cost are needed to make any decision when spending other people's money
- Deadlines kill innovation and reduce quality - this is only true of you're a really bad planner. All project work is probabilistic. This probabilistic (and statistical) behaviour mandates a plan to manage in the presence of uncertainty. Bout reducible and irreducible uncertainties have specific handling plans. Either margins to protect from the naturally occurring variances or specific buy down activities to protect against probabilistic occurrences of undesirable outcomes.
Here's the starting point to clarify and debunk those concepts
- How To Estimate Almost Any Software Deliverable in 90 Seconds - this the starting point for learning how to estimate for all software projects. Is it a bigger than a breadbox, or Twenty Questions approach. It's actually a Binary Search approach, that will get you an 85% confidence number in 90- seconds or less. No more excuses for not estimating anything, including things you know nothing about - assuming you are a developer with any experience in the domain. If you have no experience in the domain, then you shouldn't be estimating to begin with - go find someone who is.
Here's some more details, once it's been confirmed you have domain experience
- How Do You Estimate Work That's Never Been Done Before? - This is a common lament in the #Noestimates community. We've never done this before, so how can we possibly estimate how long it will take? Lot's of ways - Reference Classes, Parametric models. Monte Carlo models of activity networks.
- Let's Stop Guessing and Learn How to Estimate - estimates are NOT guesses. Estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
- How to Estimate if you really want to (Updated) - the key here is if you want to. There is NO reason to not estimate. Estimates are need to make decisions in presence of uncertainty.
- How to Estimate Almost Anything if You Really Want To - this starts with what's the coastline of England problem and uses a similar red herring about a hike down the coast of California.
In the end it's simple. Anyone speaking about the difficulties or the waste of estimating is likely on the spend side of the software development equation. Those on the pay side know (or should know) they needed estimates. They can get the estimates from those most qualified to provide them - the developes. Or they can just make them up. Probably better to have a bottom up estimate.
