Agile is a great thing, no fixed deadline death march, working until 11pm every night to deliver on time & compromising on quality. But in reality, not every client is going to buy into the agile process. There will come a time when you must estimate a projects cost and timescale and then sign a contract promising you will deliver. Avoiding this situation though and sticking to the agile process is an entirely different topic, what I would like to talk about is estimating software projects or more importantly why developers give poor estimations.

Poor estimations can cost you money, reputation and employee morale, so doing it well is not only very hard, but very important. I believe poor estimations come down to a few factors:

Missing requirements

There is no use in estimating how long a task will take if you are not fully aware of all of the requirements. More requirements will equal more complexity, which of course means more time to complete the task.

Estimating for testing and not estimating for fixing

All estimations should factor in testing as well as time to fix defects. Not only will it take time for unit tests & BDD tests to be written as well as testers to manually test. It will take time for a developer to find and fix the bugs once they have been found. The more complex a task the more defects it will contain as well as the more time it will take to track them down and fix them.

Presuming developers write code for 8 hours a day

Developers do not sit at their desk coding solidly for 8 hours a day. In an office environment interruptions occur throughout the day which can greatly reduce productivity, such as meetings, emails, IMs & questions from co-workers. It can take up to 15 minutes for a developer to recover from an interruption and continue working. Some days a developer will only get 2 hours of productive time.

Estimating days and not hours

All tasks should be broken down into chunks of between 2-16 hours. This is a good rule to stick by as it allows you to think about each task in isolation and take all factors into account, reducing the chance of an estimation plucked out of thin our.

Getting some other guy to estimate

The developer/developers who will be writing the software should be doing the estimations, they will have a much stronger grasp on their velocity from personal experience. This also avoids resentment towards colleagues when developer A is being held accountable to the velocity set out by developer B.

Ignoring the past

George Santayana once said “Those who cannot remember the past are condemned to repeat it”. If this is not the first project you’ve ever worked on take a look into the past. Find a project you have worked on previously with a similar spec/requirements in the same field and use that as a reference point.

Forgetting downtime

It’s important you factor in developer downtime when calculating what can be achieved. If it’s a long term project or a project during summer months developers will be taking holidays during the project. Public holidays should also be taken into account and a suitable buffer applied.

Settling on one number

Settling on one solid date or number of hours to completion is unrealistic and unachievable. The best approach is to estimate a range, best case, most likely and worst case. This gives you and your client a better outlook towards what will be achieved and more realistic expectations.

Not taking estimation seriously

Estimation is a skill in every developers skill set that should be taken seriously and worked on. Educating your fellow developers and yourself about estimations techniques and good estimation practices is good for everyone involved.

Nobody likes estimating, personally I think it is the worst part of my job as a software developer and I am sure I am not the only person who thinks this. Hopefully these points can take some of the pain and worry out of estimating projects. It’s also important to remember that estimations are never truly reliable or completely accurate, estimating is a dangerous game by nature and the agile way of working is the much more favorable path. Staying that, hopefully these points I’ve raised will take some of the guess work out of guesstimating when you are forced out of agile and into the world of estimation.