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:
- Use a Story Point burndown chart which should be provided by a good tool (not sure about Pivotal Tracker, but JIRA does this)
- Hand-draw an hours burndown -- we've done this in cases where clients have a very strict budget and we have to keep within a certain allocation.
- If you're really stuck on using hours, JIRA gives you the option to make time your primary estimation tool and can give you an hours burndown -- try a different tool.
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.