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:
Take a look at your to-do list.
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.
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
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.