I was recently asked by Aaron to do a blog post about KPI's when using Scrum (thanks for the suggestion!).  The basic idea being that many companies want to have role level KPI's, but how do you do that with Scrum, especially when Scrum seems to be about the performance of the team.  I say "seems" because it's often how people who are new to Scrum will look at things, which is unfortunate as they miss the point that scrum is concerned with not just the team's results but with the individuals in that team as well.

So, what KPI's should be considered for members of a scrum team?  At a team level it's easy enough - delivery of working software that provides business value.  But for individuals, what do we do?

The first instinct might be do look for something that's easy to measure such as taking on a certain number of hours worth of tasks per sprint, or being present on time at the daily stand up meetings, but these would be poor KPI's as they measure attendance and allocation of tasks, and not delivery of business value by individuals.  Instead I'd suggest that what we really want to gauge is how much overall value people are adding to the business and the team - and that value isn't always tied directly to their work artifacts/outputs.

Here's some suggestions for KPI's you could apply to individuals in a scrum team:

  • Positive Team Involvement
  • Mentoring
  • Knowledge Sharing
  • Proactive Alerting of Impediments
  • Working According to Team Standards (e.g. TDD, style & naming, code comments & documentation, regular check-ins, etc)

In case it's not implicitly obvious, I'd suggest that individuals in the team would have different expectations on their KPI measures.  For example, the more experienced team members would be expected to spend more time mentoring than the juniors.  The team members with greater domain knowledge would be expected to spend more time sharing that knowledge than those who are new to the problem domain, etc.

So then how do we then measure these factors?  One method might be through peer feedback, others might use independent observation, others might try something completely different.  My suggestion would be a mix of observation and feedback - the scrum master needs to observe the team dynamics and behaviours on an ongoing basis, however they often miss things that the quiet achievers do during the day, so having a peer review process is a good thing to add to the mix.  You might want to get feedback from the team at the end of each sprint or you might choose to have a 6 monthly anonymous feedback mechanism and use that with a mix of judgement to work things out.  Whatever you choose it will end up being a judgement call as to wether people met their KPI's or not.

The most important thing to remember is that in the same way that the team is measured on results, individual KPI's should be trying to measure the individuals value, not their effort or their time spent in the office.