Home  >  

The Art of Estimation Part 1

Author photo
December 30, 2009 | | Comments (2)
AddThis Social Bookmark Button

Estimating your time

One of the soft skills you'll acquire as you progress in your career is a sense of how long it takes you to do certain tasks. You'll often be asked by your manager to come up with time estimates for tasks and your schedule will be built around these estimates.

Sometimes, usually depending on the main business sector of the company you work for, you have to work backwards from an end date, like when a client needs an game or an application for a trade show. That's never pleasant. Early in my career, I worked five years for marketing and advertising companies, and they are notorious for this practice.

But generally you supply the estimate for how long you think it will take you to complete a task or set of tasks and your manager will then evaluate and report up a final time. As a manager I generally insulate estimates with a little extra time, I call it x-factor time. This covers if we run in to unexpected issues, it gives us breathing room.

You acquire this skill mainly through experience, by seeing how long it really takes you to do certain things over time.

Estimating how long a task should take

The next step in this soft skill is to develop a general understanding of how long tasks should take to complete. Not necessarily how long it would take you to complete but how long it should take an average developer to complete.

This is useful in several ways.

If you have a general idea how long something should take you can provide swags in meetings or to clients. But if you are providing swags, make sure everyone at the table understands what a swag is.

You also can use this skill to assess the progress of your developers. Are certain developers operating at a level higher than their current title? Are certain developers consistently taking longer than they should need to with certain tasks?

These are things that a manager who isn't also a developer would have no eye for, these are the things that set technical managers apart.

Estimating how long individual developers might take

Once you have an idea of how long tasks should take, the next step is to learn the capabilities of your developers. Whether running a team, multiple teams or a department, you will at some point need to manage your developers as resources for allocation to projects.

Knowing your developers' capabilities and general time to complete tasks will allow you to better plan ahead and estimate needed resources. You will need this skill when running multiple teams or departments and your business unit plans out the coming year's worth of projects - you will need to be able to respond with resource needs and straw man time lines.

In the next part of this series I will explore the different types of estimates you can provide.

Read more from Tom Barker. Tom Barker's Atom feed

Comments

2 Comments

Chris Gruel said:

In case anyone was wondering about swag...

SWAG = Super Wild A$$ Guess

John Bliss said:

Here's a trick I've been using for a decade now: for a given task/project, candidate hour-estimates are as follows:

0.25 hr
0.5 hr
1 hr
2 hrs
4 hrs (half-day)
8 hrs (1 day)
16 hrs (2 days)
24 hrs (3 days)
32 hrs (4 days)
40 hrs (1 week)

...anything greater than 40 hrs MUST be broken down into sub-tasks/sub-projects before accurate estimates can be generated.

Leave a comment


Type the characters you see in the picture above.


Tag Cloud

Technical Speakers

Who is the best technical speaker you have seen?

Answer

Latest Features

Recommended for You

@InsideRIA on Twitter

Archives

  • Or, visit our complete archive.  

About This Site

Welcome to the premiere community site for all things RIA sponsored by O'Reilly Media and Adobe Systems Incorporated.