Task estimation mechanism
If a User Story is estimated in Story points then how are task estimated it is no of hours or days or some points mechanism.
Why would you need an estimation in hours for the relevant tasks of a user story?
Agreed. There is indeed value in identifying the tasks needed to deliver the story solution, but if you've already estimated the story, why do you need to estimate the tasks? Relative estimation is designed to avoid time-based estimation. There is plenty of evidence demonstrating how poorly those in IT estimate time-wise. Therefore, there is little if any value in the additional effort expended to provide time estimates for underlying tasks.
Relative estimation is basically placing stories into different-sized categories. And Story Points do not add up to other higher story points - don't try to do this! Think X-Large, Large, Medium, Small, and X-Small. How many of the smaller "relative" sizes add up to a larger story? Doesn't make sense, does it?
As you can see, it is rather pointless (no pun intended) to relatively estimate tasks. And while some may prefer to provide a time-based estimate on tasks, it is my opinion that it is a wasteful exercise.
A significant benefit to relative estimating is that it is quick and reasonably accurate, especially compared to traditional estimation practices. Do not over-complicate the approach.
As you can see, it is rather pointless (no pun intended) to relatively estimate tasks. And while some may prefer to provide a time-based estimate on tasks, it is my opinion that it is a wasteful exercise.
This is in line with my first-hand experiences. Our team dropped time-based task estimation back in April because the estimates were always waaay off and provided no value to the process or the product.
During a Sprint it should be possible to sum the amount of work thought to be remaining in the Sprint Backlog, preferably by means of evidence, such as stories and/or tasks actually completed.
If the selected Product Backlog items (e.g. stories) are sufficiently granular to provide this transparency, then no further sizing of work in the team's plan may be necessary. If not, then the more detailed work in the plan (e.g. tasks) may need to be sized. Since it is comparatively fine-grained, time-based sizing of this work may be viable. Tasks, for example, are frequently sized in hours.