The Facts and Fictions of Estimation

The most important, yet most error prone aspect of a software development project is coming up with feature estimates. This is a process dreaded by everyone on the project, which is largely because no one has a clear idea of how to go about producing estimates. Rather than give tips that may-or-may not be applicable to your situation, I prefer to address all of the misconceptions that lead to disaster when coming up with or interpreting estimates.

  • You can estimate bugs
  • You don’t need to look at the code to estimate
  • Longer estimates become shorter if you add more people
  • Over time, estimates get better
  • You can get accurate estimates
  • You can use estimate to determine date of delivery
  • Senior engineers are better at estimation than less senior engineers
  • Estimates for new features are the as good as estimates for feature enhancements
  • Refactorings can be be estimated
  • Testing the results of the Refactoring can be estimated
  • Developers can do estimates by themselves
  • Estimates don’t impact Feature Prioritization
  • Estimates don’t have to be measured in hours and days
  • Estimates should come from a group rather than an individual
  • Estimates can be done by upper management
  • Estimates are not Commitments
  • It’s going to have to be built regardless of estimates

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s