Lately I've noticed a fair amount of discussion surrounding the utility of task estimation.  The question seems to be: is it really useful to estimate the time required to complete tasks, or is it unnecessary and counter productive to estimate such small units of work? If we're already using some form of estimation for stories, is task estimation really all that useful, or is it in fact thinly veiled micro-management?

• relative estimates, as is usually expressed in [story] points and applied to stories.
• absolute estimates, as is usually expressed in time (hours or days) and applied to tasks.

Story points are used to estimate the effort, or size as it may be, of user stories and provide us with a means to approximate the effort of those stories in our product backlog. These estimates can be considered both relative and coarse-grained. We say they're coarse-grained because the points do not represent a precise calculation of time; they offer a sense of the magnitude of effort associated with a story. We say they're relative because they're only meaningful when compared to either (a) the point estimate of other stories, or (b) the accumulative points of the stories completed in a prior sprint (i.e. our velocity).

Then there are the fine-grained, absolute estimates. Such estimates are measured in units of time - e.g days or hours - and are usually applied to tasks - those action items that result from the work breakdown of stories. Teams that estimate tasks, typically do so within the sprint planning meeting. Of course, they only identify, and estimate, tasks for no more than one sprint of scope at a time.

It is the latter of these two - the absolute, fine-grained estimate applied to tasks - that seems to be in question.

First, estimation encourages tasks to be sized reasonably. I try to encourage teams to strive for a work breakdown that results in tasks that require effort in the range of a couple of hours to a couple of days. I consider tasks of this size to be reasonable because I, as a team member, ScrumMaster, or even casual observer, can see when something is getting out of hand. I can see it quite easily and within only a few days, without having to monitor the minutia of everyone's work. If something is estimated to take a couple of days and there's no sign of completion on the horizon in 3 days then I can ask "is there a problem?", "do we need to consider another approach?" or "can someone help?".  By wanting to know if something is getting out of hand, have I designated myself singular owner of the project?  No, not at all; as a member of the Scrum team I have the right and the responsibility to know when lack of movement on something is snowballing out of control. Further, I've always believed that the daily stand-up (aka Scrum meeting) helps us keep our finger on the pulse of the project. That's only true if there's something pulsating - that is, there are tasks being completed each day.  That requires that we keep our tasks in the range of a couple hours to a couple days. Too small, and the work breakdown itself, as well as managing the information, becomes a considerable amount of effort, and it creates noise that can obscure real information. Too large, and we don't know until the last minute (i.e. the end of the sprint) when tasks - our approach to solving a problem - are in jeopardy and could benefit from some collective scrutiny/discussion. For a team that intuitively lands on tasks that are sized reasonably, this particular purpose for estimation may not hold much value. But until your team hits its stride, task estimation may help develop that intuition.

Setting Daily Expectations
Second, by estimating tasks in time, we set daily expectations among our team. That is, we let people know when a task should be reported as complete; of course, allowing for a reasonable margin of error. If tasks are not estimated, then hearing someone say "I've not completed my task" or "I'm still working on ..." doesn't have any meaning at all because it could very well be a very large (multi-day) task. On the other hand, if we do estimate our tasks in units of time, then we know as the person is speaking about that task if it is within its proximity of its estimated time allotment, or if its already in trouble and deserving of a little help. 

Recommendations
So should you and your team do both forms of estimation? Or more specifically, is task-estimation worthwhile?  That depends on whether or not you see value in these two functions: keeping tasks within particular size range, and helping to set and manage daily expectations. Frankly I've found that task-estimation to be very useful in the early stages of learning agile development.  But, it is just as true that over time, as improved skill and intuition help us stay within a reasonable range for task size, the practice becomes less important. But [agile] development is not about following one formula. It's about finding what works for you right now, and adapting to change - including changes in your own personal development.