Six Estimation Safety Tips

Predicting the future is hard! These suggestions can help you avoid estimation quicksand.

Karl Wiegers
Analyst’s corner

--

A dartboard with several darts randomly stuck into it.
Image by Marc A from Pixabay

Most people need to prepare estimates for the work they do, but we don’t do a great job of estimation in the software industry. In this article I offer six safety tips to keep in mind as you prepare estimates for your project and for your individual work.

Estimation Tip #1: A goal is not an estimate.

A management- or marketing-imposed delivery date is not an estimate — it is a goal. A team of a certain size and productivity level can produce only so much high-quality functionality in a given time. Tutorials on how to estimate often are presented as though the body of work to be done is precisely defined and the goal of estimation is to determine the corresponding effort, cost, and time needed. Sometimes, though, estimation works another way. If some capability absolutely must be delivered by a particular date, then the estimator needs to determine how much functionality of given quality will fit into that time box. This is the premise behind sizing user stories in agile development and fitting them into a fixed-size sprint.

Commitments should be based on plausible estimates, not just desired targets. A piece of work should not be considered…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com