Most often, a specific project will adopt agile to improve their ability to deliver high-quality code in a more collaborative way and often must adopt a combination of different agile practices. For the team, collecting metrics is important to help them learn and adapt their practices. Typically agile teams need metrics to answer questions like

• Are we on track to deliver what we committed to for the iteration?
• How much value have we delivered to business?
• How much value can the team deliver with remaining time?
• We need to plan for the next Sprint. How much work can we commit to?

In my experience agile teams need metrics, I agree with Richard in that good agile metrics:

• Are easy to collect and don't become an impediment to the team's work
• Measures business outcomes over activity (e.g. value delivered vs. number of tasks completed)
• Looks at trends, not just a single point in time
• Encourages whole team results over individual results.

The team also uses measurements at different times in the iteration (sprint): either before, during or after. And why they may use the same metrics they may use them differently or interpret them differently. For example - measuring the team velocity in conjunction with defects (or better yet "technical debt" which is a combination of defects found after the sprint and any uncompleted but committed tasks) is often used to help the team understand what value they can commit to delivering in the future. Here are some comment metrics used by the team:

• Are we on track to deliver what we committed to for the iteration? Iteration Burndown (normally measured in effort in hours)?
• How much value have we delivered to business? Release Burndown (story points)
• How much value can the team deliver with remaining time? Release Burnup or Story Point Progress (story points)
• We need to plan for the next Sprint. How much work can we commit to? Team Velocity story points / iteration)?