Estimating Features: options, context and God
“We need to support registration in the application. Here are some details, how many days to develop?” — Where should you start from? Should you simply throw a number? Maybe read it first and use your gut feeling, your experience? Is there a trap here? Although there are no recipes for estimating successfully™, I want to elaborate on the options in front of us, before we dig into the details.
Guesstimate everything months in advance by 20 seconds of thought
If you are able to read a Feature specification and give estimation based on “whatever works for you”, you win! For small features this should probably be as simple as pie, but what about the big ones? Still easy?
“We have someone who can do it with some sort of dark magic ball !”
I call him (or her) God. If you have God in your company, you win!
(1) Estimate by detailed breakdown
Giving proper estimation without feeling bad about it 10 seconds later is not cheap. I don’t care how much experience you have. So, are you ready to invest? You should not only consider coding effort, but also organization time – testing, deployment, monitoring, bug fixing etc. After you have this in mind, did you consider risks? What about 3rd party integration? What about inexperienced developer who might work on this feature?
One way to provide detailed estimation is by actually doing the Design (of the solution) and bring one to the table; This means doing a Design Review with your peers, break the feature into tasks, estimate hours needed per task and give very solid numbers. You can do it by yourself, you can do it with others; the price is not 20 seconds, but this is highly useful for solid estimation.
Wait, Context is king!
Before you start throwing numbers into the air or diving into an expensive design to come up with estimation, what is expected of you?
1. Purpose – how your estimation is going to be used? To determine roadmap? To understand feasibility? For prioritization between 2 Features? Each might require different “estimation plan”
2. Size – is it good enough to say “it’s a big feature” or maybe “it’s around 20-40 days” or maybe “it’s 24 hours”?
Back to your options list
Well, you could estimate by detailed breakdown, if you really need low granularity. Sometimes, rough estimations might be enough. What now?
(2) Estimate by personal hunch
You can obviously estimate based on your personal hunch, taking into consideration organization time, risks and what not. In many cases, assuming you’ve got enough “gut feeling” built by your sheer experience, this should suffice to build roadmap or understand feasibility. If this is the expectation, it’s probably the cheapest way to provide numbers.
(3) Estimate by collective hunch
You can improve (or at least feel more confident) granularity by adding one or more experienced teammates into the mix, double-checking your hunches and forming a collective hunch.
(4) Estimate by team hunch
Again, more people involved might mean better estimation, due to larger feedback. There is the obvious risk of “2 people, 3 opinions”, but at least you’ll have some other, non imaginary, voices of sense.
What does it all mean?
Each method offers some advantages and suffers from some inner faults. Understand the context and pick wisely. Accept the fact that things change and features might be thrown away – do not waste time on estimation more than is really required. More about features estimation to follow…