For agile to work, it's important to evaluate how your team and your project are doing. Qualitative feedback, such as from reviews and retrospectives, can be valuable. But at some point you may need more quantitative information to improve your project.
There is a wealth of information on things to measure and how to use the data you gather. I'll review a few methods here. While evaluating the various things you can measure, be mindful of how metrics can be misused if they are out of alignment with larger goals.
Visualizing the state of your project can be useful for understanding how well you are working toward your goal, though less quantitative project visualizations can still help drive improvement. Even a daily team agreement on the status of a feature (green/yellow/red) can help a team focus on what to work on and identify times where the "numbers"—such as burndown charts—conflict with the actual project state.
Project monitoring tools can be important for agile teams to understand how best to meet their goal, but they are only one part of understanding how well the team is doing in their quest to adopt agile methods.
The Agile Atlas has an article reviewing some metrics that are useful for agile teams, both for improving sprint effectiveness and understanding how the team is doing as a whole. These metrics have the advantage of being relatively low-cost to collect.
Jeff Sutherland proposes a number of quantiative metrics that focus on the team’s effectiveness delivering value, and Bob Galen also suggests some metrics to measure predictability, value, quality, and team health. The blog Implementing Agile has more thoughts on useful metrics for Scrum teams. Looking at these ideas may provide some useful insights for your team—if you take the time to consider what the metrics are telling you before acting on the results.
While metrics focused on delivery are valuable, you may still find it useful to measure the team’s alignment with agile principles. Likewise, team happiness is an important part of an agile process. While "happiness" can be tricky to quantify, Jeff Sutherland describes a happiness metric to do just that.
Though measurement and goals are essential to implementing an agile "inspect and adapt" process, figuring out what to measure in a quantiative way can be tricky. It can be useful to try evaluating a number of metrics, then seeing what information you can get—and whether that information could lead to useful action. If the metrics are low-cost to collect, you don't have a lot to lose, and you stand to have much to gain—so long as you remember to inspect and adapt your metrics gathering process as well.
What metrics do you gather for your agile team? Are they useful?
