2 ms·
I have been frustrated by the lack of resources on how to estimate software tasks for the past 8 years and had essentially come to agree with micro2nd that esti
by afarrell 8y ago
I have been frustrated by the lack of resources on how to estimate software tasks for the past 8 years and had essentially come to agree with micro2nd that estimation was impossible. I was, however, searching for some method which would turn it from [impossible task that I had no idea how to do or how to learn how to do or how to ask how to do] into merely difficult work.
However, this past summer, I got a new manager who has had a goal of introducing estimation into the team and I've been working with him. The biggest thing I've learned so far is that if you're estimating by asking "how long will this take?" then you're asking the wrong question. To estimate, ask instead "What are the mile-markers?"
The work of answering this is to go through the research process of determining what the task involves. This takes significant time and so it is still important to stand firm and resist the urge to give a number when someone asks you during a meeting if you haven't prepared. It also is still fallible and I'm honestly not all that practiced at it yet. However, at the end of it, you'll have mile-markers which provide the three pieces of real value from estimates:
1) A rough intuition for the level of complexity of the task.
2) An opportunity to notice when you can cut down the scope of something or when you should prepare for something by doing a small refactor.
3) A way to judge your velocity as you are doing the task.
The third one is particularly important and can make guessing a number an actually-somewhat-useful activity. Why? You can guess numbers for the individual mile-markers and then, if after a while of working notice you are falling behind or moving faster, you can communicate with stakeholders.
----
When I've asked for advice on estimation, I've often been told "just gut-check yourself and multiply by 3. The important thing is to communicate when you think you might not hit the estimate." But if right after producing a single number and saying it, the alarm starts blaring in your head saying "I'm not going to be able to make that estimate." well... you'd feel silly "It will take two weeks. Oh I think its going to take longer than two weeks." and so you never have a point where it makes sense to raise a flag. But if you have mile-markers and a regular habit of checking yourself against them, then there is a defined point where you can raise an alarm.