Time Tracking -- Essential for better estimates

Posted: Friday July 31st, 2015
Last modified: Friday July 31st, 2015


Before diving into the content of this article, here is an overview of some key points to ponder while you read.
  • Better estimates can produce more accurate budgets
  • Better estimates lead to on-time deliverables
  • Better estimates (and proper conceptual planning and requirement gathering) lead to accurate quotes
  • Approaches with Agile and Lean work! Things like "story points" are great at estimates. However, additional steps can be taken to produce development hour estimates, if time is tracked
  • Time tracking can bring to light areas where you might have time that can be redeemed in your work day, to be more productive.
  • Personal Process can be improved by analyzing things such as time spent designing vs time spent fixing bugs. Heck, even time fixing others bugs vs own bugs ;)
  • You can deliver some epic status reports to your superiors with stats and graphs -- it's an impressive bonus to time tracking
While in school one of the topics that really persuaded me was PSP, Personal Software Process. The topic has many avenues to explore. One of the things I liked about it was the idea that with practice I would be able to give an accurate estimation of how long it would take to develop some software. Up until that point, my development practice was, "Oh yeah, that's a cool idea, time to code!" The idea was almost fantasitical, like "yeah ok, this is software development; there is no such thing as acurate time estimations"

For several months we broke down software development related tasks into 2-5 hour deliverables. These deliverables ranged from UML diagrams to software components. We planned and made estimates on our various programming tasks. Then we recorded all of our time spent (at first by hand, until that portion of our tool was done). Ultimately we built a time tracking tool that analyzed our time tracking effors. It was pretty neat looking back, but at the time everyone hated it.

Needless to say I went from being lucky if I was within 50% error on my estimate to within 10% in less than two years. My stats in a team environment are still improving, there are more variables that can be changed such as teammates lagging on something you're task is dependent on.

Even modern software development practices that make use of Agile and Lean have a form of estimation. For some practices that are founded on those principles, often times story points are used instead of hours, but the overall principle is the same:
  1. Take a look at your to-do list.
  2. Determine how much work you think it will be. Where work can be hours, points, a scaled rating 1-10, etc. It is important to be consistent with your estimates.
  3. Then for a set cycle/sprint/period-of-time, track and see see how much work you actually get done.
Over time, you can corrolate your estimates with actuals. Statistically speaking, over time your estimates to real result will balance itself out. It will account for those "OH SOMEONE HELP ME!" moments when you realize you are way over your head. It will account for sometimes, you're smarter than you remembered and things worked on the first shot. It will even account for the hours you spent talking in the office, phone calls and/or emailing. None the less, your ETA on code will get better as time goes on, but you need to track your time and/or effort as well as results to make that corrolation.

As for me, I personally like to know how much time I actually get to develop. At that I also find it interesting where I spend my time. For example I noticed that when I spent more time designing, I almost always had a considerable less amount of bugs. Some areas of interest might be:

Administrative Which includes tasks like but not limited to: Meetings, phone calls, emails, reports, reading, scoping, misc. documents, planning, scheduling

Bugs such as: determining and assigning bug origin, bug fixes, testing bug fixes

Coding Tickets/tasks, Scripting, mockups, prototypes.

Designing Architecture Descriptions, Requirements and Specifications, UML diagrams, Components, high/low level descriptions.

Reviews

Testing Iron out those bugs while the code is still fresh n your mind!

Transportation (this one is more for fun) such as walking to meetings, driving, heck bathroom breaks because you drank way too much tea/coffee.

Anyway, if you need something to help you along the way, check out my stop-watch page! It won't do the analysis for you, but at the least it offers (at the time of writing) a way to easily stop-watch your time.

Developed by Arthur Weborg

r2msoe@gmail.com