What are good metrics to use to measure the performance of a team using Agile software development methodology?
I’m a little leery of metrics when it comes to guiding team performance. Once you pay attention to just one or two variables it becomes very easy to fall into gaming (intentionally or otherwise) the metric and fool yourself that you’re improving – when all you’re doing is improving the metric. For example metrics based on velocity can “improve” by the team moving to smaller stories (less work per-story – so more stories completed – so velocity goes up). That might be a good thing if the stories are useful user stories that deliver smaller increments of business value. That might be a bad thing if the stories become smaller more “technical” tasks they don’t deliver real value by themselves. The closest I’ve seen to a metric that generically useful is Running Tested Features (RTFs) which are, to quote from Ron Jeffries’ article on the topic: • Running means that the features are shipped in a single integrated product. • Tested means that the features are continuously passing tests provid
There are lots of different metrics you can use, but they’re likely to be very dependent on how you’re implementing your Agile/Scrum processes. Here are a few suggestions: 1) Velocity – As the key to understanding how much work you can deliver and over what period of time you can come closer to release, Velocity is a very important metric. The higher the velocity, the more value you’re delivering each sprint, and the sooner you can get your work into the hands of your end-user customers. Generally, determining your velocity is done using mathematical equations, such as the average of the last seven sprints, minus both the largest and smallest sprints in the sample. 2) Story Points – Depending on how you’re managing your backlog, the size of the stories that you’re delivering each sprint and/or each release is another good metric. It balances the work that your team is doing with the business value that you’re delivering to the end user. Keep in mind that this is slightly different than
