Estimating hours for work to be performed is a traditional way of estimating how long a project might take someone to do something. And what’s not to like about using hours as an estimation technique? Its a universally understood metric that makes all sorts of fun calculations and planning possible.
Unlike standard jobs out there where you may know on average it takes 3.2 hours to create a widget, software development is still largely an art form which is highly dependent on the skill of the craftsman.
The pitfalls – What can go wrong with estimating hours.
Overestimating ability – Something appears simple, so it gets underestimated.
Pride– Some people don’t want to appear inexperienced, so they may estimate something much lower than the actual amount.
Skill level – An experienced software developer can crank out something quite quickly while a junior developer has to add learning curve time to overall development time. Thus when software development is done by a team, using hours isn’t a very useful metric.
Gaming the system – Once you decide to measure something by hours, your developers will quickly figure out it’s easy to game the system and give artificially high hour estimates.
Overestimating the amount of development hours a day– In a workday, a federal developer may only have 3 actual pure hours for development. Think about it.
- ½ hour paid break
- 2 hours of meetings per day ( if they are lucky)
- 1 hour of reading/ responding to email
- ½ hour responding to instant messaging
- 1 hour work of people stopping by, bathroom, paperwork, etc.
- 1 hour of writing/reading documentation.
That’s 5 hours of a workday gone to essentially overhead.
Blocking Decisions – It may be 4 hours of work- but, it takes 3 months to get the decision made for the developer to get the code done.
So what to do.
If you have to use hours, understand the pitfalls, and make sure you do not over commit your team.
Start changing the culture. You may have to do some education around why using hours are wrong.
Keep your teams out of useless meetings and anything else that contributes to overhead. A half hour weekly meeting consumes 26 hours of development time in a year.
Look into other ways of estimating.
With most craftsman / artists they are better at estimating the size of a job. “That’s a medium sized job”
With software teams its better to get a feel for the amount of effort required to do something. This is why you see so many efforts surrounding abstract ways to measure effort. You see modified Fibonnaci series, t-shirt sizes (xxs, xs, s, m , l, xl, xxl) , dog size(poodle, lab, Great Dane.. etc). Essentially making the estimation fun but relate-able.
Really advanced teams have been able to move past estimating altogether as an exercise.
Watch for me to post more in the future on alternative ways of estimating effort.