Measuring agile software development team's performance

Many would say, if you want to do it wright, there is no a proper and a good way how to do it but I have my favorites on this topic. Its like with every business or process in life, at some point you would like to know if the process is efficient, do you have a satisfactory performance, are you doing a good job, is there a space for improvement and if so what would you need to change.

The similar topic could be raised in the field of software development life cycle and one of my favorite advices is to measure/analyze team's performance as a whole and associated processes and ways of working rather then measuring performance of individuals. Focus should be on identifying team's weak points and process bottlenecks so that you could draft a meaningful plan for improvement.

So lets get started, first thing that you would need to measure is about productivity or how fast could you deliver a feature to the stakeholder in a fixed amount of time. In order to analyze it properly you could start from measuring the cycle time ( cycle time can be most simply measured from when work starts to when the work is done ), shorter the cycle time the more things are getting done in a given timebox. In most cases, having that measure as a number wont be enough so it would be beneficial to dive deeper into its root causes and get the detailed overview of what is going on under the hood ( are the high numbers caused by too long coding time or you are maybe suffering from inefficient code review, acceptance and verification processes.). If you are getting low numbers, that means that you will receive the feedback pretty much earlier in the process and for sure on time especially in cases where you did it wrong ( requirements not met ).

The next step is to put your focus on examining the planning process of your team and to learn more about its predictability. This is very useful especially if you need to deal with complex projects, customer's commitments and important deadlines. You need to know your team's commitment reliability in order to be capable of promising any kind of a deadline to a stakeholder. Measure itself its pretty much simple, you need to calculate the ratio between the planned scope ( initial or final ) and the completed scope at the end of the sprint. If you are constantly hitting low percentage, it means that your team is struggling with their planning and commitments and it is a clear indication that you need to find a way to improve it ( possible reasons could be that the team is bringing in the work that is not well refined - to big user stories or tasks, too many surprises could appear during the sprint which would then cause a lot of spillover and unfinished work ).

Another important thing to measure is, of course, the quality. My favorite measurements are:

• MTTR or mean time to recover ( also known as lead time ) or how much time you would need to spend in order to fix the issue. You can easily measure it on average and that will help you to know your pace and what could you expect when you are getting hit with issues/bugs. This could be measured for different products/components, different priority/severity levels and of course for different projects and customers.
• Escaped defect rate - this measure tracks overall quality and is the connection between customer satisfaction and the team. The lower the defect rate, the more satisfied the customer is likely to be with the product. With a high escaped defect rate, even the most awesome product is going to have a lot of unsatisfied customers. Escaped defects are measured by the number of problems (bugs, defects, etc.) found in the product once it has been delivered to the user. Keep in mind, though, that until a “story” is done, it is still in process, so any issue identified is not a defect, it’s just another task to complete before the work can be considered “Done.”

The last but not the least performance indicator is the team health. It creates awareness that puts the beforementioned metrics into better context. If all the other metrics are perfect and happiness is low, then the team is probably getting burned out, and fast. This is the human side of the equation and low happiness score is nearly always a sign of underlying problems and can be a leading indicator of something else.