How To Track and Measure KPIs for the Team

This article will talk about the main principles used in defining team KPIs. Throughout the body of this article, there is a review of a few examples of team KPIs for production in IT departments. This paper also investigates the key rules and risks involved in the development and use of KPIs. It aims to highlight a good approach for teams to define, track, and measure KPIs on their own. The article gives a low down on how to develop KPIs for development teams in Pivotal Tracker.

Introduction

KPI (key performance indicator) is a term that is becoming increasingly popular day by day.

Almost all management conferences ring about this topic and discuss it at length. While all that is true, do you know why KPIs are important? The answer is that KPIs help a team set its goals and then measure performance and results against those set goals. A goal and a measurement of performance is needed to bring a strong feeling of responsibility within the team. This feeling will stretch to each and every task they do. Once your team knows that their performance is being monitored, they will start thinking about how each step they take brings them closer to their goal.

Simply put, this is what takes a normal routine team away from their arduous work and makes them think differently, out of the box. In any outsource IT company, when the product for sale are lateral services that includes development, design, management efforts, etc. The need to have team KPIs becomes even more important since it helps when the people working have a product mindset and are able to see the business value of the products they are developing.

KPIs for Different Departments

An average IT company has two kinds of departments, production departments and non production departments. Generally both types of these departments will develop their own KPIs. When we take a look at marketing, HR, sales, or any other non production departments versus production departments, the need for each of them to have measurable indicators of their work is emphasized.

Recruitment departments for instance have very clear goals: employing people for hot open positions versus employee dismissal in case they lack the skills needed. So KPIs for them could contain the following parameters (per defined period of time, i.e. one month) as:

  • Number of open vacancies
  • Number of found/contacted candidates that are good fit for a certain position
  • Number of interviews conducted
  • Number of test task given
  • Number of closed positions
  • Number of people fired because of not being able to pass trial period etc.

Then they will look to wrap all of these figures into a pre set formula to give us measurable KPIs that would be able to gauge and reflect the department’s productivity.

Another good example can be the marketing department and its work on leads. In this case, the main parameters would be the following:

  • Number of people contacted for the 1st time (per channel of lead generation)
  • Number of cold leads received
  • Number of leads converted to hot leads
  • Number of closed leads etc.

Having said that, it must be mentioned that there are some important rules on how to properly build team KPIs, which are outlined in multiple writings. There are a considerable number of articles and blog posts that cover this topic. A few of these are outlined below:

To summarize the points from these references, here is a list of the important rules discussed in the above mentioned articles and blog posts.

  • Choosing
  • Tracking
  • Measuring
  • Revisiting

Practice is an important part of developing team KPIs by the team on its own. A good concept in KPI development is when the team itself decides exactly what KPIs to use and why. The team is responsible for the impact of its results on the whole company, the product that they build, and the business that they do. It’s a good approach to adopt since nobody from other departments/teams in the business or the top management will be aware of the specialization of the work and the results that can be achieved.

In such a case, autonomous independent teams are created that are focused on a KPI designing for products that attract customers and derive growth. These teams are accountable — to each other — for moving their KPIs and making a difference to the customers. Individuals in each team are accountable to one another and their team. Since there is no point in doing something unless it changes the metrics, the team is working on what KPIs to build, how to measure them, what results will it bring, etc.

One cycle of build-measure-learn can typically look like this:

  • Team agrees area they want to focus on
  • Team captures data / and analyses data around the KPI they want to impact
  • Team identifies significant work for the customers/company wish to impact
  • Team uses data and metrics to evaluate developed KPIs and gotten results.

Risks in Building KPIs

Despite the apparent benefits KPIs have to offer to businesses, there is also heavy criticism to this technique, and using KPIs is considered risky, especially if they are used as criteria to give rewards. In this case, a team member gets his/her reward/salary/bonuses/etc. based on their KPIs. For a software developer, it can be number of features implemented, bugs fixed, etc.

Unfortunately though as Dan Pink mentioned this is not something that is effective and known to produce good results. It’s also proved by other organizations, research institutes and companies.

Nevertheless a large number of IT companies continue using KPIs for rewarding, but from my personal experience almost always such approach comes to be very counterproductive.

KPIs for Development Teams Using Pivotal Tracker

There are plenty of tools for counting and showing measurable KPIs for development teams. One of the most popular tools among them is Pivotal Tracker. Below are a few examples of the services that this system can provide.

On Image 1 you can see the timeline (February 25th through April 25th) of all tasks with status described as 6 different options. There options are:

  • Accepted
  • Delivered
  • Rejected
  • Finished
  • Started
  • Unstarted

Having such a graph helps them get a clear understanding of the amount of work that has been finished, is in progress, etc. for the certain project milestones.

On image 2, there is a breakdown chart that shows pretty much the same information but in different ways. In this case, we see the points remaining to accomplish all the work planned for the milestone that had a timeline of January 12th through to April 30. This graph gives the team a clear work dynamic and what is actually needed to implement all the tasks according to project plan: when to speed up, what are bottlenecks, etc.

Image 3 is a picture of the amount of features, bugs, and chores that have been done. This is extremely helpful to evaluate the quality of work that the team’s doing. The result is not about hours spent, tasks resolved, but of course about quality: how many bugs are produced versus features done.

Conclusion

Having team KPIs helps all the stakeholders understand what goals need to be set and how the team is looking to reach out to these goals. Before developing any team KPIs, it’s good to define what the key parameters of describing team results are and how to track and measure. Using member KPIs as if-then rewards is quite risky because it focuses on one person making KPIs instead of all of them focusing on the product. A good approach when a team is developing its KPIs is to try and accomplish it on their own. There are tons of tools that can help you measure KPIs, but before any implementation and measuring, it’s important to understand the ‘why’s and ‘what’s associated with the proper key performance indicators.


Originally published at workshop.masterofcode.com on September 21, 2015.