> There are a lot of formulas on how to do estimates, and everyone has their own rules. I also have my own rules.
The actual way to produce estimates can be found in the excellent book Thinking Fast and Slow by Daniel Kahneman: you have to consider a previous project (or, better, several of them) of roughly similar in size and scope, and use that as an anchor for this estimate. You're allowed to add or remove a bit because of a slight difference in complexity. But the golden rule is never to say that this other project doesn't count because, although it seemed similar at the start, it encountered unexpected problems. That's the whole point!
If you haven't worked on a project that large (or kept good enough notes about how long it took), well, tough luck, you can't produce an estimate, any more than someone who doesn't know any software dev at all can.
Looking back at a project with this in mind I was surprised to find the distribution of subtasks (into 3 big buckets of "main complex logic", "simple GUI", "reports/presentations") was roughly equal rather than about 80% on the first one as I suspected. There's no way a rule like "add 40%" can help you with something like that.
The book discusses a great example where they were preparing a university syllabus to teach various biases, including the underestimate bias and this very technique to avoid it, and they still underestimated how long it would take to prepare the course (even after being given information about how long previous courses took to prepare!).
Another recommendation in the same vein is How To Measure Anything by Douglas Hubbard. And Superforecasting by Tetlock. Estimation/forecasting (same thing different emphasis) is a problem we know quite a lot about, and we know how to train people to issue calibrated estimations.
The actual way to produce estimates can be found in the excellent book Thinking Fast and Slow by Daniel Kahneman: you have to consider a previous project (or, better, several of them) of roughly similar in size and scope, and use that as an anchor for this estimate. You're allowed to add or remove a bit because of a slight difference in complexity. But the golden rule is never to say that this other project doesn't count because, although it seemed similar at the start, it encountered unexpected problems. That's the whole point!
If you haven't worked on a project that large (or kept good enough notes about how long it took), well, tough luck, you can't produce an estimate, any more than someone who doesn't know any software dev at all can.
Looking back at a project with this in mind I was surprised to find the distribution of subtasks (into 3 big buckets of "main complex logic", "simple GUI", "reports/presentations") was roughly equal rather than about 80% on the first one as I suspected. There's no way a rule like "add 40%" can help you with something like that.
The book discusses a great example where they were preparing a university syllabus to teach various biases, including the underestimate bias and this very technique to avoid it, and they still underestimated how long it would take to prepare the course (even after being given information about how long previous courses took to prepare!).