First of all I strongly believe that a developer shouldn’t estimate tasks that are believed to be larger than 40-80 hours. On this kind of estimation, a lot of things might go wrong and it’s the Project Manager’s job to do the estimate (with help, of course) and calculate the risks.
Developers are sometimes required to estimate entire projects. Either they work as freelancers or part of small teams, people expect from them to estimate entire projects.
So, if you are required to do estimations, without getting into details, here are some tips:
Do high level estimations first
This is called Rough Order of Magnitude Estimate (ROM Estimate). As the name describes, nobody expect from you at this point to produce exact estimations. They just want to know roughly about how much money the project will cost them and decide if to do it or not. So don’t waste to much time on this kind of estimation, as it’s possible that the project will not even be done.
What you should do is break down the project into module (or layers, if it’s easier). On each module try to understand exactly what needs to be done, but without getting to much into details. Don’t be afraid to ask questions. Make sure not to miss any modules the project will have.
Usually, on this kind of estimations, the actual development time will be plus or minus 50%( or even 100% in some cases) difference from the ROM estimate.
For this kind of estimations it’s better to rely on expert opinions. Ask people who have done this kind of projects before, do research online, ask your cat if the project it’s about mouse catching. Or use your own experience with this kind of projects if you have any.
After the project has the green light it’s time to do some detailed estimations.
Break the tasks into the smallest pieces possible
At this point, any modules that need to be developed should be broken down as much as possible. But, even at this point, there are some features that are not clear. Try to split the tasks into categories: small tasks, medium tasks and large tasks. When dealing with a large task, try to do some iterations for splitting the task in smaller ones.
As this is the actual estimation on which you’ll work or be paid, you need to make them as exact as possible. So spend a lot of time on this or you’ll regret later.
Never leave time reserves
Even after multiple iterations some tasks are still to large or unclear to be estimated exactly. At this point, developers tend to add some time reserves on the estimation.
This should never be done as you’re basically messing with the whole schedule of the project.
What you should do instead is to just give them a ROM estimate. Just mention that the estimation is not exact, it’s a ROM estimate, or give a best case / worst case scenario estimation. The client/product owner will know how to handle this risk.
Estimate for the person doing the tasks
If you are also the one working on the task, estimate for how long it will take you to complete it. If you unsure on who will do the task, explain that it’s a ROM estimate and risks might arise.
If you have some colleagues/team that can help you with estimates it’s always a good idea to use the agile approach: planning poker. This will usually lead to discovering new issues that you never think about yourself.
There are a lot of techniques for doing estimates and, if needed, you should study them but for the day to day life of a developer this tips should be enough.