Get certified - Transform your world of work today

Close

Agile and KPIs

1 October 2015


Agile and KPIs have been a hot topic in 2015. Before I share my views on the subject, let's take a look at what Agile and KPIs mean.
  • Agile is the early delivery of business value (credits to Henrik Kniberg and Alistair Cockburn).
  • KPIs are key performance indicators (a performance measurement).
For example, if we think about the KPIs of a shoe factory, they would be something akin to the number of shoes made in a period of time, or the number of shoes without defects made in a period of time.

KPIs are (and should be) closely related to the output of workers. In the example above, it is shoes. If we try to translate this idea into traditional software development, we potentially have the following KPIs:
  • KLOC (kilo lines of code)
  • Meeting deadlines or milestones
  • SMART (specific, measurable, achievable, relevant, timeboxed) objectives accomplished
So if we follow (successfully) the factory example above and apply it to software development, we basically need to understand what the "shoes" are in a software development team. What's the team's output?

Consider what the KPIs of Agile teams should be. I believe you have a choice between the following two categories.
 

Intangible metrics approach

The intangible approach includes metrics such as:
The team's average velocity in:
  • Story points
  • The number of user stories (throughput)
  • Business value points
The commitment (delivered versus committed) of each team in:
  • Story points
  • The number of user stories (throughput)
  • Business value points
The user stories' average lead time (in days or hours) for each team:
  • How long it takes for a user story to move from "in progress" to final status (usually "accepted") on your team's physical or virtual board.
The predictability (velocity average deviation) of each team:
  • This metric shows how stable or steady your team's velocity is. Remember that two teams can have a velocity of 20 points, and one is constantly delivering 20 points per sprint while the other delivers 10 points in some sprints and 30 points in others.
I really don't believe in having KPIs attached to logged working hours, so I won't mention any of those in this article.
 

Tangible metrics approach

This approach includes tangible metrics, such as:
  • Number of defects per release
  • Code coverage percentage
  • Number of releases versus rollbacks
  • Number of broken builds (and how long to put the build back to green)
  • Availability and response time of your product
So, why do I call the first approach intangible metrics and the second one tangible metrics? The metrics that I call intangible themselves are basically vanity metrics. They don't mean that much. Who cares how many points a team can deliver if you deliver a buggy product to your customers? The truth is that the intangible metrics (alone) usually lead to story-point inflation, distortion of user stories, misleading information, bad decisions, and sense of unfairness, demotivation, and frustration among teams.

The tangible metrics are much closer or related to the output of your team -- your "shoes," or the product. The data is more meaningful than the data provided by the intangible metrics. Are your teams working for the KPIs or are the KPIs working for your teams?

Think about what the output of an Agile team is:
  • Story points?
  • Number of user stories?
  • Accurate or inaccurate estimations?
  • Early business value?
My advice to you is to first consider your context or reality and then combine both approaches and make sure that your teams are happy. Happy teams tend to deliver more value than unhappy teams.

Now it's up to you to decide what your KPIs will be: The ones in the intangible approach? Maybe the ones in the tangible approach? Maybe a mix of both? Maybe none, and you try your own approach. Bear in mind that KPIs that make perfect sense in a given environment, company, organization, context, or reality may not be suitable in different ones. You, and only you, should determine your KPIs, because you are the one who knows and understands your reality.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.2 (16 ratings)

Comments

Homero Leal, CSM,CSPO, 6/9/2016 10:28:42 AM
Great simple explanation!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe