Once a specification of a new feature has been designed and agreed. This work needs to be broken down into small pieces. A practise I describe in my post about specification documents.
Once the tasks are broken down and listed is time to estimate these tasks. The temptation here is to estimate by time. For example, this should take me two days. Therefore, two points? Or it might take a week, is that 1 week point or 5?
Sounds reasonable once you agree a unit of time, right? Now imagine you have a task that you have not done before. Therefore, needs investigation, research and maybe a spike. How do you estimate something you don't know? This is where time based estimation falls over.
Estimating based on complexities and unknowns is a much better method of estimating tasks. For example, if you have never done it before then it's a high estimation. Let's say 8 points. Now you could get lucky and everything just falls into place in a day or two but that is likely to be rare and will even out over the course of months of projects.
Another interesting factor to consider are tasks that have dependencies on external teams. This often causes “more work” then you think when thinking in time. There will be communication, reviews and round of feedback which you are likely to forget when estimating tasks like this.
Here is a quick guide I wrote for my team. In which, I use the Fibonacci sequence provide the integer's.
The smallest unit of work. A task that has been done many times and is not dependent on any other people. No review is required.
A task that is fully known and has been done before. May require a review before being complete.
A task that has multiple factors. There are no unknowns but will require a review which may result in back and forth.
A large task which you feel comfortable completing. This may be something you have not done before but is not very complex.
A task that has external dependencies or multiple people. May require you to research an aspect of this task.
A complex task that you have not done before and has external dependencies. This task may require pairing with another person.
You’re doing this wrong. You should consider splitting this task into smaller tasks. If you cannot split this then this task should be completely unknown.
Remember, the point of estimations is to derive a velocity in which you can rely on to confidently commit to work over short periods of time.
Estimates don’t need to be accurate, they need to be consistent. Your velocity over time corrects for inaccuracy of our estimates.