How to correctly estimate development times

Published Nov 17, 2017
How to correctly estimate development times

One of the most common problems in every development team it's how not to fail in estimating product release date.

The issue

There's always something that wasn't considered, changes made in the middle of the process or people leaving and/or resigning. Developers are people and they do get sick, depressed, have personal issues and lot's of other possibilities.

When there's a product design team that shows new features to the bosses without consulting with developers first this gets even worse.

Solution

The most used methodology is trying to estimate how long each task it's going to take and then "do the math based on previous similar tasks". This doesn't work.
It's really hard to find another similar task, event with the same title, there are always going to be new variables, and not every team member works the same way.

This can only work properly on Software Factories where the teams basically build 3 or 4 similar products with a different skin.

Real solution

Take each task to a depth where it's impossible that task can take more than 4 hours. This way each developer should be able to complete 2 tasks per day.

Completing tasks not only shows progress, it's also motivating for every team member.
A single taks taking more than one day has lot's of issues:

  • Hard to measure progress
  • Next day you have to remember where you left off. Worst if the weekend it's between those days.
  • If the developer assigned gets sick, it's really really hard for another team member to understand what the previous developer was doing and how much is done.

Having no more than 2 tasks per day has another benefit's: daily SCRUM it's not boring or unnecessarily long. It's easier to know what each developer it's doing and who is needing help. There's more collaboration among the team.
This last thing it's specially important if you have junior developers who want to learn but are afraid to ask.

Total time estimation

Lot's of Product Managers have the horrible adiction to just start adding numbers and set a tight deadline.
There can be mistakes, people get's sick, depressed, they have personal issues.

The best thing to do it's calculate how many tasks are there, 2 each day, how many developers and before setting a deadline add between 15% to 25% of overhead development time.
If a task was harder than it sounded, if someone isn't working as expected the deadline isn't moved.
Your development team it's awesome and they made it before deadline? Great! Maybe your team can now develop some extra features and you can give them some kind of bonus (extra vacations, paid bonus or even a "let's hang all day together with a great barbacue and pool" bonus).

Take care of your team, it's really important, the most important factor in estimating time. Ask them how they feel about the company, about the product they are building, what they feel it's wrong, what they expect from you as a Company, are they enjoying their work? All of this matters, taking care and feeling that the company cares about you helps a lot.

If you have a team that goes to a physical place, please, don't try to create activities beyond working hours, some developers study, have families, friends, do sports, whatever...

Discover and read more posts from Federico Ratier
get started