How long will this take?
As a programmer, you are constantly being asked 'How long will it take'?
And you know, the situation is almost always like this:
- The requirements are unclear. Nobody has done an in depth analysis of all the implications.
- The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.
- You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
- The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
- No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.
- Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked for an estimate and they expect you to give a reasonable answer. It's part of your job. You cannot simply say: I don't know.
You know Estimating is hard. Working with NO estimates is a pipe-dream. So it's sort of a necessary evil.
Here are the set of tips:
- Whenever you encounter an estimation problem, try to split them in to smaller pieces. Then see if you have already done stuff similar to the pieces. If you have, you should already have a fair idea of how long each piece takes. If you don't, you should start to actively keep track of time taken for various kinds of tasks. This will help you in future estimations.
- Try to find a similar task - in the same domain or involving similar technologies.
- Give your estimation as a range rather than a single point estimation
- Understand your margins - if you're estimating something completely new you might need to take a 2 times or even 4 times in factor (i.e. if your estimation is 2 days and the factor is 4 times, it could take between .5 a day to 8 days). The more uncertainty, the higher the factor.
- Understand that as you progress on the task, you need to revisit and refine your estimation
- Communicate, communicate, communicate! Make sure management is aware of how reliable a specific estimate is (or isn't).
- Give estimates in a scales and numbers that reflect the accuracy (e.g. estimating in hours implies more accuracy than giving the same estimate in days)
- Acknowledge the "Cone of Uncertainty" (see more details below)
- When giving an estimate, let's say "3 days", think of the following question: "Can it take less than 3 days?". If the answer is No, then this is an optimistic estimate, since it would take 3 days if and only if nothing goes wrong...
- Use some method of keeping track of how long you thought it was going to take vs. how long it actually took.
- Make sure to break your tasks down into the smallest possible steps before coming up with your estimate.
- Don't forget to include testing/bug-fixing time in your estimate.
- Don't let people force you into artificial schedules.
- If you haven't done something similar, you can probably rely on other peoples experience and get an estimate from them. Don't take this at face value though. Nothing teaches you like experience of your own.
The Cone of Uncertainty:
The idea of "the cone" is that you start a project with high-level/low-accuracy estimates and your confidence and accuracy increase as you make progress on the project. For example:
- At the time of requirement gathering your estimates are much less accurate than after the high-level design is ready
- Which are far less accurate than after the detailed design was done
- Which is less accurate than halfway through coding.
Its kind of like shooting a target. Previous shots at estimation should tell you how off the mark you are, so that you can correct it.
One of my colleague (Gani Padela) shown an awesome video, which says
No good can come from a rushed job to meet a deadline.
Video explain us that we have to estimate in such manner so we equalize to Customer's expectations in relation to project delivery.
Advantages of Estimates For Developers
Unless they are working on a R&D project, don’t go into a feature with no clue whatsoever of how long it’s going to take to complete.
I’m sure that, if you’re a developer, you’re making estimates for yourself already. Of course these are not precise estimates, and you don’t need a complex process to produce them. It’s more a short reflexion based on your previous experiences solving similar problems than anything else. The result sounds like “this should take me a day or two” or “if I’m not done by the end of the week I’d be really surprised”.
It’s perfectly fine to do this: you don’t commit yourself, you don’t set a hard date. Now let’s see how your own quick estimates can be useful for the project.
Not Wasting Time
Sometimes a developer can see that a feature is not worth building because it would take too long. This is something product managers can’t know and are always happy to hear about.
Detecting Difficulties
Used correctly, estimates can help technical leads identify other developers struggling with a complex issue. This also prevents the very need for micromanagement or the “are you done yet” effect.
Finding Quick Wins
Estimates can help a developer find and communicate about quick wins for the project.
The Cost Of Estimates
Giving an estimate always costs time. It can go to a minute of reflexion to full fledged processes.
If the cost of estimating something gets too big compared to the scope of the feature, I don’t think it makes sense to be spending this time. For instance if you take 2 hours discussing whether a feature will take 4 hours or 6 hours, you are obviously wasting time.
Overall, I recommend not spending more than a few minutes on estimates. If you end up with a huge project, try to break it into smaller bits and estimate these instead of trying to deal with the whole thing.
