Estimating is hard. Hours, days, dollars, story points, function points, use case points, lines of codes … whatever — they are all tough. The only reliable estimates are based on prior experience.
If you have never performed a task before there is simply no way to estimate how long it will take YOU. 3 people may tell you it took them 3, 5 and 4 days respectively. Assuming you have a background similar to theirs, it MIGHT take you 3-5 days. Then again, it might take 2 or 6. How would you know?
Take a team of software developers and it gets worse. They have different skills, habits and productivity rates. Their development tools and environments are constantly changing. There is turnover on the team. The process they follow keeps evolving. It’s hopeless!
Well, not quite. Estimating a task or set of tasks for the first time will always be an educated guess.
It is critically important that you track team performance on every project. Provide an initial estimate using whatever approach makes you most comfortable then track actual effort against the estimate.
The idea is to build up a history of completed activities in the form of tasks, stories, functions, use cases and/or projects. When a new activity comes along, you can refer to the history and predict the effort required to complete the new activity.
A perfect solution? No. You still have to factor in variables such as the tool set, environment, staff turnover, etc. But, at least you have a solid base to build on.
It is shocking that so many development teams fail to track their performance history. For each new activity, they take a new educated guess. It may be educated but a guess is a guess. Customers need factual information not guesses.
And another thing — always estimate as a team. Never rely on a single individual — particularly a manager.