A Method for Getting Early Estimates Right

 

A Method For Getting Early Estimates Right
Jakob Persson
Co-founder of Node One

Early Estimating

A method that uses your prior experience when making early estimates. By doing so, you can make estimates accurately and more effectively, not just hunches or intuition. Estimating is like taking a blurry picture and trying to figure out what's in it. What you find may surprise you!

What is an Early Estimate?

"Estimation is the calculated approximiation of a result which is usable even if input data may be incomplete or uncertain." -Wikipedia

Early estimates are done before the project starts, later estimates come when you are planning work within your team.

Early estimates are based on a feature. It's based on blurry client requests and we just need a low to medium accuracy estimate. The purpose is to decide on investment. Early estimates are usually developed by a single person.

In-project estimates are more accurate, and can be based on user stories. They are used in planning, and the best approach is to get a group consensus.

Even with a slight effort, you can get a pretty accurate estimate.

Early estimates:

  • Can be made in relatively short time
  • Generate estimates that aren't based on merely random guesses or chance
  • Yields estimates that are suited for their purpose

The Method

1. Timebox your estimation work

When you're estimating, decide how much time to spend doing the estimation work. They key in your estimate is in the requirements that the client has provided.

2. Analyze the requirements

Look for complications; things the client has overlooked, implied or assumed, but may have overlooked. Keep in mind your experience with prior projects. Come up with ideas of how to solve problems. Take note of any questions that come up.
Check out our exmaple: bit.ly/drupalestimating

3. Make Initial Guesstimate

This is your gut feeling of how long this project will take. We'll be using it later to compare the output of your estimation.

4. Extract Features and write proposed solutions

A feature is something you deliver. It's not something you do with the feature module!

A feature is a conceptually and contextually discrete piece of the final deliverables with a proposed solution

Go through and estimate the amount of time needed to complete each feature. If the client provides you with wireframes, that's great, because it can help detect the client's assumptions. At the end of this, we end up with an estimation sheet including:

  • the estimate number
  • description
  • estimate
  • degree of experience
  • proposed solution

5. Estimate Features

Choose a scale, such as the Fibonacci sequence, and only use those numbers. If you estimate 3 hours for a feature, round up to the next number in your scale.

  • Changing Settings: Factor 0.1 (~5 mins)
  • Building functionality using Drupal's UI: Factor 1 (a few hours)
  • Developing new modules or themes: Factor 10 (dozens of hours)

6. Taking Uncertainty and Errors Into Account

There can be many factors to uncertainty:

  • Requirements that weren't investigated very well
  • Poor coding practices
  • Poor development process
  • Inexperienced personnel or developers
  • Incomplete or unskilled project planning
  • Lack of automated source control
  • Developer gold-plating

Overlooked Activities

  • Migration of Data - It can take an insane amount of time!
  • Producing help or documentation
  • Deployment
  • Integrating third party systems
  • Working with a third party
  • Performance
  • Stability
  • Security
  • Usability

Off-the-cuff Estimation

  • Propose well-tested solutions you have used before
  • Research solutions by googling, reading articles and blog posts
  • Prototype solutions in Drupal
  • Avoid solutions that require integration with unknown third-party solutions

That gives us a scale from 1-5:

  • You have done the exact same thing before in other projects (uncertainty 0.8x - 1.25x)
  • Someone else at your company has done it in other projects (uncertainty 0.67x - 1.5x)
  • You have read about a way to solve it (uncertainty 0.5x-2x)
  • You can think of a solution that seems possible (uncertainty 0.25x-4x)
  • You have no idea how to implement a solution (?)

Based on the uncertainty in this scale, you can give the client a range based on your estimate in hours and the degree of experience with the feature. This can be calculated automatically by your estimating spreadsheet.

Did you enjoy this post? Please spread the word.