Today's Time Log Is Tomorrow's Historical Data

The only good way to create any kind of a reliable estimate is by using (your own) historical data.

If you are trying to create an estimate for a new project and are having a hard time, don't lament your lack of historical data. The best thing you can do is to set up a system for tracking time on your projects. Today's time log is tomorrow's historical data. (When I say "you" I mean either you, singular, if you work alone or you, plural, to refer to your project team.) Do the best you can on this estimate, recognize that it's probably a bunch of nonsense, and move forward.

Before you start working on the project you just (mis-)estimated, plan how you're going to track time spent on it. This doesn't mean you have to establish the Time Tracking Committee, hold a dozen meetings every day, and publish a seventy-page document describing how time will be tracked. Just pick a solution and spitball it past your team. Lightweight is best for a first pass, you'll be able to get a feel for what works and what doesn't in your situation.

Some things to keep in mind:

  • You might work a nominal eight hour day, but you probably spend less than three actually working on your project. Meetings, support for previous projects, and the water cooler suck up a lot more time than you realize.
  • Some meetings are directly project-related (design review, etc) and should probably be charged to the project. Oooh, I said "charged". Don't get too uptight about applying all of your time to one bucket or another. Keep it lightweight and easy to implement and you'll increase the likelihood that you'll be able to stick with it.
  • Spreadsheets can be a convenient way to track time for individuals or small teams. If a team is going to use a spreadsheet-based solution, take a look at Google Docs and set up a shared spreadsheet.

At the end of the project, you can compare the actual results to the estimate you made. Disappointing, eh? Don't worry, you'll get better with practice and as you build a data collection.

See also Software Estimation: Demystifying the Black Art, by Steve McConnell. This book is an excellent resource.

"Software Estimation: Demystifying the Black Art"
Posted on 2009-01-20 by brian in timelog .


These are great points. The one that especially rung true for me was the myth of the 8-hour work-week.

I've started using a (personal, private) automatic time-tracker and your estimate of 2-4 hours is about right, especially if you discount doing email. In my case, email is part and parcel of the job, but it's still an important factor in trying to schedule non-interruptive tasks.

I would encourage everyone to grab a free, automatic time-tracker. Don't let your boss see it of course -- this is for you, not her. Make it automated so you're not wasting time with it.

This isn't as accurate as manually recording everything, but I think at the beginning you just want to know about low-hanging fruit.


Jason Cohen
2009-01-20 19:44:12

Thanks for the encouragement. This will be a (mostly) free timetracker hopefully next week.

What are you using for a tracker?

It's funny, I got burned by my 14-project-hours-per-week rule of thumb. There's so much other stuff to do beyond just getting the code to work that my 60-hour workweek [I don't want to keep track any more] allocated about 2 hours to coding! So I had planned to launch on Monday, but at this point that just ain't gonna happen. Lesson: don't leave out critical items from the estimate, like how long it's going to take to get all of the mechanics of hosting and deployment set up...

2009-01-25 05:24:11
Comments on this post are closed. If you have something to share, please send me email.