Improving the accuracy of software project estimates: multiply everything by 3

I found when I'd worked in software for a couple of years that everything I delivered took me about three times longer than I expected.

Eventually I realised that my 'gut feel' for estimating a coding task was 'about how long will it take me to code this if I make no errors & get it right first go'. Which is a good starting point for an estimate, so long as you then go on to add testing, debugging, changing or misunderstanding requirements and time to release.

If you have stable requirements and a pushbutton deployment toolchain, then 3 x gut feel is may be about right. That covers clarification of requirements, testing, subsequent clarification of misunderstanding, and deploy.

If you haven't got those things, x5 or higher is usually closer.

I notice that others have found something similar. I'm please to find that multiplying by 3 puts me about 4.7% ahead of the curve -

One thought on “Improving the accuracy of software project estimates: multiply everything by 3”

  1. There’s always a ‘fudge’ factor when trying to layout realistic deliverable completion times. Some do x2, some x3 like you, others 4-5x.

    Why? Are we as programmers just a deceitful bunch? No. We just know better than planners with no tech experience that time used THINKING can’t always be accurately measured – nor should it be. When we’re forced to chop time off of tasks, it almost always comes back to bite you. You were forced to take a quick fix approach to coding, the product suffers due to time constraints that do not factor in the valuable human input that is impossible to decouple from quality software.

    Nice article.


Comments are closed.

Improving the accuracy of software proje…

by Chris F Carroll read it in 1 min