Gantt
During your planning phase, Gantt charts are very useful, they really help the stakeholders understand what has to be completed. The problem with the charts is that can become extremely complex and can contain 100’s if not 1000’s of tasks all tied to dependences. When the dependencies are so intertwined once you change one you affect all the other parts of the chart that means reworking which means maintaining the chart becomes a fulltime job. You will also find that the chart has the inability to show the evolution of the development project, it starts very quickly to be impossible to compare estimates you performed for the project. (Current time, estimated time)
Burn-Down
Agile frameworks use Burn-down charts; the key to the chart is it shows the amount of work it will take to complete the project. They are extremely easy to understand, the line (going down hopefully) is called the burn-down velocity. Basically, it will show the team is how many hours per day the team needs to finish their tasks so they can complete the project. The charts help with estimating, if we have a continually moving down line then we are very good at forecasting and might be able to get a few more stories in the iteration, if it is going up then we need to get better at our estimates.
Conclusion
What I have done in the past is to use the Gantt chart for initially creating the entire project plan so we start to understand all of the dependencies in the development project. You can also use a Work Breakdown Structure (WBS) chart to uncover dependencies, and then use the Burn-down chart to track the weekly work and trajectory of the project throughout its life-cycle. Management as well as team members like the lean and mean structure of the burn-down chart, it is a very effective tool for communicating the remaining work over time, amount of work the team is estimating, hours per day the team needs to complete the iteration, and will the current resources implemented be enough to complete the project on time.