Updated: Jul 30, 2019
In my role as an Agile coach and Scrum trainer, I get the chance to talk to a lot of Scrum Masters and teams. When I ask them about what their team is measuring, the most common answers I hear are velocity, story points, and burn-down charts. Makes sense, many Scrum Masters learn about those topics in an introductory Scrum course. Velocity may be fine when just getting started with Scrum, but armed with more knowledge and acting as a servant-leader, I want people to improve and get better business outcomes. What about business value metrics, I ask? Doesn't product quality interest the developers, as well as code health and the amount of technical debt hiding beneath the surface? Team health? Flow of work, from the time the team starts working on a Product Backlog item until your customer is using it?
Did you know that velocity and story points are not even part of Scrum or found in the Scrum Guide? And are you aware there are better metrics awaiting your exploration? In this article I discuss the proper way to use velocity if you are using it, the misuses and pitfalls, why it may be time for you to move beyond it, and suggest some metrics dimensions you should explore and experiment with.