That's more "Cowboy".
The common tools I use are burn-down and burn up charts for iterations and for releases. It gives you an idea of what you have left to do for each milestone at a quick glance, and whether you're in trouble.
Over the last year, I've leaned towards just doing burn-up's and only at the story point level. Once you start tracking hours against tasks, the management cost increases exponentially without the corresponding benefits. You could theoretically extract resource utilization data from it, but I rarely see that data used. Remember - There's no point capturing data if you're not going to use it.
In the example below, the story point goal was ~800 points. The dark green represents what was accepted by the PO. Due to organizational dysfunction, We were utilizing more of a kanban approach and were demonstrating as soon as features were completed and tested rather than waiting until the end of a sprint. This method had pro's and con's which I'll discuss in a separate post.
We emphasized with the team that it's much better to get stories done and accepted all the way through the cycle and not letting things sit and slamming QA and the PO at the end.
After several iterations we started seeing these patterns in the burn-up:
An almost perfect linear line from iteration start to the goal.
That's a good thing right?
Or is it a little too perfect?
To answer that - you have to understand the team, the environment and their motivations.