Use metrics to provide the information you need to drive your inspect-adapt cycle. If a retrospective indicates the team has a problem, collect data if you need it before making any process changes.

And use a burndown chart if you're doing iterations, but not if you're using a kanban-style flow.

The developers time to complete tasks is a essential metric because estimating of tasks is an important agile technique and IMO there's little benefit in doing so without checking the accurateness (especially if your team isn't experienced in estimating).
You don't have to use a burndown chart, but it is useful and [quite easy to create]). I would just try it for a iteration and see if it provides benefit for you.