If you have enough information to have broken it down to that level, you shouldn’t spend more than a minute on each one. You’re not going to be correct anyway, but you’re going to be as correct after a minute as after an hour.

If, on the other hand, you were talking about user stories, I would suggest getting the stakeholders in a room and spending five minutes asking questions before estimating.

Regardless, don’t waste much time doing estimates. They’re not useful or accurate enough to be worth the effort.

In my experience, one of the core ‘yeah, that really works’ pieces of an agile approach is the ‘Tasks should take less than a day’ guideline. If you’re estimating things that take longer than a day, you’re going to be pretty far off.

Once you’ve broken them down so you can do that, you’ve done enough; regardless really of what those things are.

In the agile scrum methodology, Planning Poker is seen as an effective way of using the whole team to rapidly estimate the effort required for the user stories in a sprint (presuming this is what you are talking about). Otherwise, I wouldn’t spend any more than a few minutes estimating a single task that is part of a user story.

I would highly recommend using this consensus-based technique if you are attempting to make estimations for a team of developers.

Planning poker means that you can get some pretty good estimates for every single user story within a single session (no more than 1-2 hours).

Do some reading on this and give it a try!

Also, as a general rule, no task in a user story should exceed 7.5 hours (a single day of work). If it does, you need to break the task into smaller tasks.

I think it depends on what you need. If, for example, the resources allocation of your project depend on it (as was the case around here sometimes), it is better to do it carefully. In the other way if you are doing a project that does not have this kind of necessity you may not go into too much detail. Spending too much time on it is not a good idea cause to do an accurate estimation is very hard.

There is a famous concept called Cone of Uncertainty and Cone of Uncertainty at Wikipedia that says how much accurate an estimation usually can be. It is worth reading about.

What do you get out of your estimates?

Depending on what you work on, accurate individual estimates might be relevant (customer is paying you at the end of the week or task/story is blocking to others and a precise ETA is required) or not (you got 200 stories in the backlog, nobody is going to die if a story shifts for a week, and you’re counting on estimate errors to average out ok over a large number of them).

Just spend the minimum amount of time to get an estimate that is good enough for your needs. There is no formula.

Personally, I consider than more than a minute or two means that you’re probably estimating the wrong thing (split it up or plan discovery).

Actually you need estimation to help other stakeholders assign relative priority – so broad-based estimates that at least say task1 is roughly 3 times effort compared to task2, (even if in terms of hours its not very accurate in the end) are useful. Spend as much time is needed to understand what those tasks are (for achieving certain goals) and then having rough estimates for them.

Once you have relative priority, just focus on doing things and adjust estimates en-route. In other words, spend little time in up-front estimates, but do refine your estimates as time goes so that the project plan gives a good idea when what is going to get done.

Good estimates are the once that are based on facts not assumptions.

Thus, if you already had a similar project(s) and captured your previous estimation time, that might server as a good estimation base to start. However, depending on your project scope there might be unknown artifacts, which is better to clarify with BA or product owner asap.

It is also true to say that : Software Project Estimation is Inherently Inaccurate.
However, there are some realistic estimation practices that might help:

• People who do the work, should participate in the project estimation
• Bring in the experts: Expert judgment is critical to project success
• Estimate large pieces as a range
• Use the Delphi Technique: This is a method that helps converge opinions of the team should there be a conflict in software project estimation.
• Keep in mind the cost
• Keep in mind the allocated resources available to perform the work