Agile and Scrum metrics

Sometimes facts are misleading. There are better ways to track progress with Agile projects.

It is really important to take all the typical Scrum metrics with a major grain of salt. All of them -and the ten others not included here- have major flaws in their conception or usage, or both. In the Scrum guide itself, the reference after all, you will not find “burn down charts” or these other metrics. The guide does suggest to use metrics, of course, as part of inspection and transparency, but it does not specify what real metrics must be.

This is because every backlog item is likely very different from others. This lack of homogeneity means mixing apples and oranges is unavoidable. This is why metrics based on these will likely mislead. The other reason this often fails to live up to expectation is the attempt to mix two concepts in the same metrics. For instance, mixing value for customers and time to build. Separately these two measures are great and extremely useful. But combined they end up being meaningless.

You should not combine value with time, in a single metric, apples and oranges.
I recommend using better and simpler metrics. Use value (story points or other evaluation of value to users) for customers in product backlog prioritization. Use time-only based metrics (not value) for sprints, status or progress monitoring and forecasting.

Read the full Kinalta article about Agile productivity.