Hours burndown chart

Task level burndowns can indeed hide risk. As you suggest, towards the end of a Sprint there may be only a few task hours left...but they might be spread across all stories, and no story might yet have actually met its acceptance criteria.

However, what is really needed is a Done increment. Where task complexity is high, then a task burndown can be more truthful in this regard because it shows the fine-grained totality of work rather than individual story completion.

In my experience hour level burn downs on tasks are usually "imposed" by management, PO, or SM to help make sure the team is getting their work "done" (often when teams are self-organizing super well). In this context I haven't seen them help teams coordinate on work or self-organize more because the organization really doesn't understand or support this. In these cases i have typically tried to help the team move away from hour tracking and look at completed done stories as the only benchmark to help let them self-organize around actually getting work completed not just "the tasks they were assigned". This requires working with the organization itself to help them understand why this is more valuable.

Now on the flip side i am working with a distributed team right now that self decided to coordinate using a lot of task tracking and it is working very well for them. So i wouldn't say it is right or wrong, but how/why it is being used that determines if it is helpful or not.

Task level in hours is very time consumming.
But task burn down chart is still usefull, whatever the unit (even "just" the number of tasks is OK for me).
It is usefull in parallel with a burndown in story point.
I like to confront new Dev Teams with both burndown.
The task-burndown can help the Dev Team evaluate the amont of work, where the UserStory-burndown can help the Dev Team challenge there focus on a limited number of item.

For me, metrics are only as useful as the consistency in the methods used in generating them.



What do I mean?



It doesn't really matter if you are using story-points, task hours or done/done based parameters to track your burn-down (amount of defined set of work carried out over a fixed time scale), as long as the team is consistent in applying those parameters and everything else being the same, the variables will always show the same pattern or distribution of values on the burn-down chart or any other display model for that matter.



What is important in achieving value from the use of the burn-down chart is, whatever parameters they choose, it needs to be able to help the team generate metrics that are in line with their particular landscape challenges and one they can interpret comfortably.