“Scrum is founded on empirical process control theory” says the Scrum Guide. That really just means that rather than just guessing, we base our decisions on observations. We experiment and we learn.
To help with these observations and to see how we’re improving over time (or not!), we measure things. Metrics are useful for several different purposes:
1. Product performance
These metrics will be based on whatever our main focus is right now, for example:
- The number of new user registrations per week
- How much time each user spends with our product each week
- How many visitors we get each week
When will a particular feature be finished? What features are we likely to have when? A couple of examples:
- Velocity (story points completed per sprint or the number of stories completed, if all stories are small)
- Release burn up (the total scope of the release in points or stories and how many we have done so far, enabling us to forecast when we are likely to finish)
3. Continuous improvement
Are we getting better at what we are doing, e.g.
- How much value do we deliver each sprint? This can be hard to assess but one way to do it might be using value poker.
- Team happiness, for example using the Spotify healthcheck model.
Choosing the right metrics
When choosing what to measure, there are several things to consider:
1. Don’t impose metrics on the team
Work together with the team to identify what to measure. They are the ones who get measured. Make sure they agree that what is measured is important and that improving these metrics would be valuable.
2. Make sure the metrics are within the team’s control and important
This should go without saying but if the team can’t do anything to affect a metric or if what is measured doesn’t matter, that particular metric is not the right one for the team.
3. Don’t measure things “just in case”
Not only will extra metrics require extra work. Measuring too many things also makes it hard to know what is important.
4. Pick “cheap” metrics
If it’s too much work gathering the numbers, chances are it won’t happen. The more automatic a metric is to generate, the better! But don’t move your sprint task board into an electronic tool fore the sole purpose of generating data.
5. Make the metrics visible
A spreadsheet hidden on the Scrum Master’s laptop or on a shared company drive isn’t of much use. Out of sight is out of mind. Instead, make the metrics visible through big charts on a whiteboard (great, as it is easy to update!) or a wall.
6. Add metrics when needed and remove them when not
When some particular problem or goal has been identified, introduce metrics to determine whether the solution is working. For example, if the number of bugs is getting big, you may want to visualise the total number of outstanding bugs and how many were introduced and how many were fixed in each sprint.
And when the metric is no longer useful, simply stop measuring it and focus on something more important instead.
7. Look at the trend
When it comes to continuous improvement, the numerical value of each metric is often not that important. What matters is how the value changes over time. Are things moving in the right direction?
Make use of your metrics!
So, these are some criteria for good agile metrics. However, remember that measuring things in itself doesn’t have any . It is only useful if you act on what they tell you!
I hope you found this blog post, which is a rewrite of a previous post, useful. What agile metrics do you use? Share your experiences in the comments below!