The last and final piece of any software estimation is knowing what you don’t know.
Let’s review…
Experience gives you the background to know what type of problem you are trying to solve, what should I be asking, what pieces of history and context do I bring to this estimate.
Knowledge is the frame on what do I know about this domain, is this my area of expertise and what do I have that I can leverage to fix this problem.
Understanding the Problem is about avoiding the trap of glazing over the problem and not getting a proper description and/or understanding of it.
Experience, Knowledge and Understanding the Problem – they all help you to provide the most concise estimate on your end deliverable. However, even our best estimates are sometimes wrong (and some could be most of the time wrong), so what are we as developers to improve our estimation technique?
Add Slush.
Yes, add Slush.
Here’s how I have found that it works for me. When defining an overall estimate to a problem, I tend to err more on the side of granularity so I can properly lay out all it is that I have to do. Some would rather put everything into one mammoth task (fine for them), but I disagree with this approach for a few reasons that include;
- People can’t look at that task and tell what is being done- it’s too large – there isn’t enough information there.
- Have you really thought about the problem? Or is this a generalization of what you think, in which case you are pretty much taking a plate of food and throwing it against the wall and seeing what sticks.
- You’re keeping more in your head then in your Task list – i.e., you write some database access code on a 20 hour task… how much time do you really remove/decrement your task by? Is that what you originally estimated as? When your task estimate is so large, you are forcing users to read between the lines on what you have said.
By making your tasks more granular, you are now able to look at all these tasks and add a degree of slush to each task – some might have zero slush against them, some might have 25%? After going through each task, you generally arrive at an averaged number where to complete X work you are looking at Y % of slush.
But does that % give you? It shows your level of confidence in solving that problem – “I think I am within 15% of being correct on my estimates based on everything I know”. If you are presenting this estimate to your Team or Project Lead this should be a signal to them of how confident you are in your analysis and how close your estimates are going to be. If you are saying you are at a 50% slush, you are not confident in your estimate and really don’t understand what you are doing. And this can be a legitimate reason. If it’s a new problem set or a new platform, you probably don’t know how it all comes together, that’s life, stop worrying about it and add some slush. If anything the large amount of slush you have assigned is completely valid and you are sending the signal that you don’t know to your Team Lead or Manager.
In short…
Slush = Confidence
If you wanted to put everything together into one simple calculation – it might look something like this;
(Experience + Knowledge + Understanding of Problem) x Slush (Percentage)
And really, that’s it, Experience, Knowledge, Understanding the Problem and adding a little bit of Slush are the core factors of any estimation. There are smaller pieces surrounding an overall estimate such as; not over thinking the problem, not applying the acceleration factor, time to delivery, etc. But I’m going to address those in a final entry in a different way.
