Burndown chart is one of the most well-know charts, and often used to track Agile projects.
What are you trying to improve? I know it's bad form to answer a question with a question, but in this case I think it's appropriate. A metrics program has a half life of about 3 months under normal conditions. When working with an agile team, it could be even shorter. So you really need to have a goal for your metrics AND a plan for how you're going to generate insights from those metrics.
Every team is different. Context changes rapidly. Without knowing what you want to improve and how you'll use the information, the question you've asked is near impossible to answer.
The key metrics to pay attention to are:
Sprint goal success rates: A successful sprint should have a working product feature that fulfills the sprint goals and meets the scrum team’s definition of done: developed, tested, integrated, and documented.
Throughout the project, the scrum team can track how frequently it succeeds in reaching the sprint goals and use success rates to see whether the team is maturing or needs to correct its course.
Defects: Defects are a part of any project, but agile approaches help development teams proactively minimize defects. Tracking defect metrics can let the development team know how well it’s preventing issues and when to refine its processes.
The number of defects and whether defects are increasing, decreasing, or staying the same are good metrics to spark discussions on project processes and development techniques at sprint retrospectives.
Total project duration: Agile projects get done quicker than traditional projects. By starting development sooner and cutting out bloatware — unnecessary requirements — agile project teams can deliver products quicker. Measure the total project duration to help demonstrate efficiency.
Time to market:Time to market is the amount of time an agile project takes to provide value, either through internal use or by generating income, by releasing working products and features to users.
You can use a platform like QAppAssure which allows you to test on-cloud and on-field devices, across 100+ device, make and models, Integrate with Jira, CI/CD tools, and also use Appium, Calabash, Espresso, UIAutomator, XCUITest.
You can also track the lead and cycle time for features in the product backlog.
Lead time is the entire life of a feature from the time it is added to the backlog to the time it is completed. The Cycle time is from the moment action is taken on a feature to the point where the feature is completed/delivered.
These are a bit more common in Kanban but would work in a few contexts.
Also, I have to echo what others have said here. We should be very careful with our metrics. They can have unintended consequences. Such as cutting devlopement or testing corners to get something out before the next release. One way to combat this is to balance a metric that follows productivity such as task or feature completion rate over time and compare that to a quality metric that measures bugs, rework, or customer satisfaction.
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.