I think tasks estimation and tracking progress based on story task estimates almost always leads to tasks becoming pseudo user stories within large and overestimated real stories.
When estimating stories we encourage developers to use points and to show only relative size within the whole set of stories. I think it’s much harder to do with specific, usually technical tasks – you start judging between activities of different type, for example implementing some component and designing user interface. In other hand estimating tasks quickly falls back into estimating in man-hours and might lead to tracking people instead of real progress.
Surprisingly when implementing our tool we found the feature request “Tasks estimation” to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers.
So what works for you? Why do you want or need to estimate tasks within stories?
For project tracking? You can track stories. The story is done when all tasks are done. When you have small stories you don’t need to wait long for visible effects even if you iteration is a month long. For making sprint/iteration burndowns? You can do it successfully with stories, but again you need them to be small functional parts not epics. If you have two big stories for one month then agreed, you burndown made of stories won’t look any helpful.
Or maybe somewhere down there you need those man-hours and strict task assignments for your manager/boss? So are you brave enough not to do that :-)?