Types of Estimates

In my last article I talked about growing the skill of time estimation, and the different levels there are to the skill. In this article I'm going to discuss the different types of estimates you can provide. It's important to be explicit in the type of estimate you are providing, and to make sure your audience understands the type of estimate that they are receiving.

Swag
A swag is a stupid wild ass guess. I've also heard the first S sometimes stand for super, or scientific or sophisticated. It's not to create a timeline from. It's not to set expectations, its simply to give a rough idea of how long something or a piece of something might take.

When providing estimates there are various levels of granularity you can respond with. A swag is the most high level, needs the least amount of upfront data to formulate and is the least reliable.

An example of a swag would be: I would swag adding parental controls to the video player to be around three weeks.

This swag is centered wholly on a single aspect of a single application. It doesn't take into consideration any design for the controls, doesn't encompass any server-side functionality that would be needed to store and retrieve preferences.

LOE
The next level of estimation is an LOE - level of effort. For a level of effort you must have an agreed upon look up table to use as a key. In my office we use t-shirt sizes, some shops use a numbered rating of complexity. Our reference table is something like this, yours may vary:

small - several days
medium - several weeks
large - several months

Based on the previous example, I might estimate adding parental controls as a medium level task. Several weeks is a vague enough statement to allow time on the server end, yet its specific enough to let our clients know that it won't take months to get done.

Estimate
A true estimate involves getting as much information up front as possible. Designs, user experience flow charts, business requirements, etc and from those writing a functional requirement. Once your functional requirement is approved by your client, it becomes a sort of contract that you can then use to break out into tasks and time estimates for each task. From these time estimates real project timelines can be created and agreed upon.

So for the recurring example of adding parental controls my true estimate I might provide the following times:

create new pages for parental control configuration: 3 days
add functionality into video player: 5 days
table creation to store prefs: 1 day
create service to store and retrieve prefs: 8 days
QA: 10 days

I try to provide time in days rather than hours. Hours can lead to fractions of days and are way too granular when you are talking about something as ephemeral as software creation. Also using days as your yardstick allows you to make up time by having long days.

Read more from Tom Barker.