Characterisics of good metrics Only your imagination limits what you can measure. How does a good metric look like?

A lot of developers often are opposed to the idea of capturing metrics and being compared to others both on the team and to other teams. However, metrics are an important part of the whole process of continuous improvement. If you want to really know if you are improving, you got to have some sort of indicator telling you how you are doing. You also can’t escape the fact that management also want some metrics to make informed decisions.

A good metric first of all needs to be simple. Not just simple to understand, but also simple to collect. If a developer has to do a tedious manual process for collecting data for your metrics, it probably is going to do more harm than good. As far as it’s possible – find a way to automate data collecting. For most teams there’s a good chance your agile project management tool already is capable of capturing the data needed and maybe it even tracks the metric you are looking for already. If the metric isn’t tracked in the tool you could probably still query the data collected through the tools API. Having a decent tool could be important for making metrics simple.

Any metric you choose should also be comparable. This means the metric should be comparable with itself over time. Consistency is important. A metric that isn’t comparable with itself over time isn’t going to help you out much, so don’t bother collecting data for such metrics. An important aspect of metrics is that we aren’t necessarily focusing on a single data point, but rather the trend of that metric. The code coverage f.ex doesn’t provide that much value if you only measure it once. Yes, you get a percentage value, but you don’t know if that is going up or down – and that is what we want. We want the trends – and to be able to see trends we need metrics that are comparable to itself over time. Having said that it’s important to avoid common pitfalls such as comparing velocity across teams. Yes, velocity is comparable to itself over time – but that is within the team. Don’t compare velocity across teams, just don’t do it, please. Try to avoid comparing metrics across teams altogether. Look at trends for the individual teams as indicators for any potential problem areas instead.

A good metric must provide information that can be acted on – that is, it should be actionable. A clear plan of action and causality relation is a key element for successful metrics tracking. A metric that merely measures finite or completed actions, not ongoing activity, is not that interesting. Metrics should, as mentioned, be regarded as a trend and must trigger appropriate actions. The issue with many data points is that they are usually lagging indicators, in other words, they show what happened in the past. A metric that, when analyzed, can forecast the direction actions should take in the future is called a leading indicator.

Another key thing to take into consideration is that management will both track and use the metrics. Metrics in this respect should be honest, or said differently; you should be honest about how management uses metrics. The metrics need to be aligned with the business, in that when a metric trends upward (if thats the way you want it to go), the business value is also moving the right direction. Finding metrics that are truly honest can actually be really hard. F.ex, using lines of code to measure productivity. LOC is a terrible indicator of productivity because it is really easy to throw in extra lines of code if individual performance is measured on how many lines of code the developer is writing. Code coverage is also easily manipulated by not putting in the assert statement. Velocity as well – a team under pressure to “work faster” could easily inflate their story point estimations to please management. Finding truly honest metrics will prove to be hard if the metrics are used the wrong way by management. If metrics are used as probes and indicators of pain-points for teams as a starting point for team discussions, the need to manipulate metrics probably goes away. This means management has to realize the limitations of metrics, which might be easier said than done, right?

So which metrics should you use? I don’t really need to go to deep into that seeing as Ron Jeffries already has done an excellent job of describing his opinions on metrics. Just remember, you get what you measure.


Work less, be more productive? Sustainable pace can sometimes be overlooked, but actually it's one of the twelve principles behind the Agile Manifesto. Why is sustainable pace so important?

Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

I feel there are several reasons for having a sustainable pace. When you love doing something working long hours won’t actually feel like a grind, but you’ll loose that important “down time” that spurs innovation and creativity. A sustainable pace isn’t necessarily a long marathon, but instead a series of sprints. In between these sprints you can get a chance to re-energize and get a couple of moments of quiet so your innovational juices gets flowing again. So the practice of having sprints/iterations/cycles isn’t just to shorten the feedback loop and releasing working software often, but also helps you clear your mind and re-energize.

The research also shows that every hour you work over 40 hours a week is making you less effective and productive – over both the short and long term perspective. A worker just don’t have more than a maximum of eight hours of good reliable work hours in them each day. For a very short sprint overtime can be effective, but it’s not like increasing the number of hours by 50 percent increases output by 50 percent. An increase of about 25-30 percent in output is more typical. If the period with overtime is carried on for several weeks it’s found that the team should just have stuck with the usual 40-hour week. Also, if the team works long hours for a long time getting burned out, it can take weeks to return to normal productivity after returning to the usual 40-hours week. As the linked article says, one hundred fifty years of research proves that shorter work hours raise productivity and profits, and overtime destroys them.

Rules of Productivity

For me personally I actually feel so strongly about this that if mandatory overtime is enforced I would really, really start to consider if I am really at the right place. Earlier in my career I was on projects where overtime was “optional”. They didn’t say it was mandatory, but it was strongly advised. Back then I was both younger and lived alone, so it only affected me personally when working those long hours. Fortunately this was only a short period of time, so I didn’t feel burned out. Also, I really loved what I was doing, so it didn’t really feel like work. If I had done some research back then I would definitively have had a talk with the managers about this. For one specific project it wasn’t just a short sprint with long hours, it was more like a constant state of overtime-mentality. I really think that project as a whole suffered because of that.

Now that I have both a wife and kids it’s more or less unthinkable to have a job where I must work long hours, even just once in a while. The research backs this up – you don’t really get that more produced by increasing the number of hours beyond those 8 hours a day, and both short term and long term consequences must be payed if you do. So sustainable pace to me is a given – no matter if your workplace is agile or not.