I ask because we are looking at Pivotal Tracker, which I believe is a very popular tool for management of Scrum projects, and:
If using Tasks and updating Tasks with estimated hours remaining is Scrum best practice - why would it be left out of one of the most popular Scrum management tools and why would they not support a Sprint Burndown Chart?
I think the answer to your question is a disagreement with your basic premise: updating tasks with estimated hours is not necessarily a "Scrum best practice."
Part of the point of Scrum is to use accurate and empirical data to provide accurate estimates of the amount of work that can be accomplished. In my experience, the best practice is to use User Story Points -- at my firm we use a modified Fibonacci sequence (1/2/3/5/8/13/20/40/100) to estimate each User Story. After a few Sprints, you get a pretty good feel for the velocity of the team.
We use Story Points because they are accurate but not necessarily precise, whereas estimating in hours tends to be the opposite -- teams attempt to put a precise estimate that usually ends up not being very accurate on a task. For a long while, we attempted to estimate stories with points and tasks with hours but the amount of time we spent attempting to put accurate and precise hour estimates on each task was costing us more than it ever got us. Who needs a precise hour estimate when a team can confidently say "We're going to get 35 user story points done this Sprint"?
With regard to the Burndown chart, you have a few options:
My strong recommendation is to rethink how you estimate things and switch over to a story point, or relative sizing, method.
The best part about Story Points is, once you get a reasonable amount of time-tracking data, you can start to figure out your median and std deviation of time values for each discrete Story Point rating (e.g., the median 2-pt story takes n hours with a standard deviation of x). While I would never endorse using these measures as metrics or KPIs, I do use a method with these values to baseline estimates for Scopes of Work, in conjunction with other data and analysis of a project.
The Scrum guide says nothing about tracking and updating remaining-hours, nor does it force you to use a burndown to monitor progress. Actually hour-burns is the worst indicator of progress, as it looks good, but does not show uncertainty. You think you are on track, until you miss the mark and see there is a lot of extra work and now you are behind.
Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.
At the Agile evangelist day in Amsterdam some years back, Jeff Sutherland (founder of Scrum) said if he has to use a tool it would be PivotalTracker, but better would be no tool at all. Also he dislikes tracking hours a lot, calling it time-tracking anti-scrum. He suggest it is the first thing to ban from a company. He suggest tracking hours costs 10% of your development-time as developers hate it, because it is used to steer the wrong signals if used at all.
When talking about deciding on tools for a process I always say: Build processes around (existing) tools, do not find tools for your ideal process, because you will not find it. If you try as a development shop you might even say, the tool does not exist, lets build it ourselves! And now your are in for years of trouble.
