Estimating anything is a tricky business. Even something that you do all the time can be unpredictable. What about your commute to work? The same journey using the same car, bus, or train, leaving home at the same time every day – how long will it take you tomorrow? The same as today or a little longer or a little shorter? Hard to say isn’t it? And that’s because there are several factors that are not under your control – there could be more traffic than usual, the traffic lights could all go red as you approach them, the bus or train could be late, someone could have an accident. You know all these could happen, but you’ve no idea whether or not they will. And if they do, you have no idea how they will affect your journey and how much you will be delayed.
Estimating how long it will take to develop a new software solution is no different. You know what the end result is and where you need to get to, but there are numerous unpredictable factors that can pop up along the way. What’s the best way to account for those in your estimates?
- Estimate large requirements quickly and in large units
The larger the requirement, the harder it is to estimate. But at the start of a project, you won’t have all the details you need to estimate accurately. And if you use small units the estimate may look more accurate than it actually is. Instead, do a quick rule of thumb in large units, such as days rather than hours: “5 days but we can refine it when we know more” sounds better than “37.5 hours” which sounds more like a definite commitment.
- Learn from previous estimates
No two projects are ever the same but that doesn’t mean you can’t improve your estimates by learning from previous projects. The key is time recording: to record the actual time an item took to develop and then compare it against the estimate. Make sure that any lessons learned are documented and available for the next project team to learn from.
- Assume the estimates are wrong
Or at least not entirely accurate. All estimates are wrong to some extent (that’s why they are estimates) but it’s better to assume that and plan accordingly than to think they are completely accurate and then be surprised when there is an over-run and a deadline is missed. Agile methodologies are particularly good at dealing with this aspect of estimating.
- Assume less experienced developers will do the work
Estimates are often produced by the most experienced people on the team but this can mean they don’t allow any extra time that less experienced people might need. To prevent this, either add a percentage increase to the estimates to reflect the mix of experience or estimate based on the time for less experienced team members to do the work.
- Try story pointing
Humans find it difficult to estimate in absolute terms – how many marbles are there in this jar? – but it’s much easier to estimate by comparison to something else – are there two or three times more marbles in jar 1 than jar 2? Story pointing is a useful technique which compares each item to be estimated against the smallest item to produce a score of relative size. It’s especially useful at the beginning of projects when there is little detail about the requirements and it isn’t possible to provide an estimate in days. It’s not surprising that story-pointing is widely used on Agile projects where change and the unpredictable nature of software development are anticipated and naturally built-in to the way of working.
In summary, no one can predict the future. Especially in the fast-paced world of software development where innovation and building something brand new are part of every solution. But there are ways to improve our estimates that can help to ensure our projects are successful.
Contact us today to discuss your software development project.
