It’s the digital era and there are no ways around it: product development is fundamental to business success. But for something that’s so critical in just about every vertical, from healthcare to retail and finance to agriculture, the process of developing software can be famously difficult to manage. A lot goes into the process above and beyond the code we write – from the need to consider business goals to the desire to incorporate innovative technologies and great features.

Then there are important matters of cost and time to market. All this, and that’s not even touching upon how many different users there might be and how the product will fit into their lives. And the allocation of resources? That, too, is an important part of the software product development process.

So it’s no wonder that tracking progress is complicated. The key performance indicators (KPIs) that teams use to measure success can vary from team to team and from company to company, making it difficult for clients and other stakeholders to understand where things stand at any given moment.

As proponents of the Agile methodology for product development, we have some idea of what kinds of KPIs are the most useful – for us and for our customers. As a general rule, we like to report to them the following types of information with our KPIs:

  1. Metrics that show a continual flow of value to the customer
  2. Metrics that show how we are eliminating wasteful activities
  3. Metrics that show when customers can expect delivery of working software
  4. Metrics that show work is being properly prioritized and that the workflow is moving along in an organized way

As part of the performance-management process, here are two valuable KPIs to keep in mind to show your customers.

1. The Burndown Chart

The most common form of burndown chart is probably the Sprint Burndown Chart, but there are other types as well (see below). In essence, the Sprint Burndown Chart is a popular way to show customers when they can expect certain deliverables. Despite its jargon-heavy name, it’s a very easy metric chart to understand. The x-axis is time, whereas the y-axis is how much work there is yet to be done. As time moves forward, that y-axis should “burn down”, creating a steady downward line from the upper left to the lower right of the chart.

Simple, visual, and elegant, it can be created for sprints or projects (the Project Burndown version). Use it to track the progress of iterations or days, whichever suits your team and the rest of the stakeholders who will be viewing it. It’s a great, quick and visual way for project managers to communicate progress to a variety of different types of stakeholders, including customers.

Visually, you can keep an eye out for potential problems. The burndown line should make gradual progress rather than dropping off in a steep curve. When the curve is steep, it can mean the points at which you are measuring progress are too far apart. The solution: break down the project into smaller pieces, measuring progress more frequently over time.

The burndown line can also indicate whether the development team has taken on too much or too little. When they continually miss the mark or when they continually finish early, those are some red flags to watch out for. Others include an upward line, which could be the result of new features or it could mean scope creep.

If it’s new features, make sure they are the outcome of feedback from the users rather than features added simply because they are “cool”. In addition, a choppy descending line could indicate that estimations of progress aren’t very accurate. It could also mean that there are problems within the team – complexities that need to be addressed.

Whatever the case may be, PMs will need to interpret what’s going on for their customers.

2. Agile Velocity

This is a measure of how much “work” the team is actually completing with each sprint. This is important because with just a burndown chart, you can show that you are whipping through milestones but what good is that if those milestone don’t translate directly to business value for the customer? Agile Velocity shows the value of each milestone in business terms that everyone can understand, when stories equal value.

Measured in stories completed or hours spent, velocity is a powerful way to show customers that the team is not only producing value but it can also be used as a prediction tool, showing how much output can be expected in future sprints. Both speak loud and clear to everyone involved about the health of the team’s productivity levels. Customers love it because they get a clear picture of what’s actually being delivered to them in the sprints, measured in deliverables rather than just abstract milestones set by the PM.

Conclusion: Keeping Your Main Objectives Front and Center

The KPIs that you use in your development process are always tied to the high-level goals of your company, which affect the bottom line. Keeping these goals at the front and center of your attention while you decide which KPIs to use can help you stay on track with delivering all of your commitments, not just details of the product development phases. These would be the values-minded goals that directly affect your bottom line, such as:

  • Listening to your customers and quickly responding to their feedback on issues they might discover with each iteration
  • Continuously deliver updates to the product, as well as features
  • Balancing two types of work: regular maintenance work and the work that goes into developing features
  • Keeping track of long-term projects that are also part of the roadmap

In the end, there are tons of different types of Agile metrics to measure, including standards like Process Refinement, Cumulative Flow, Lead Time, Cycle Time, Quality of Deliverables, Velocity Consistency, Estimation Consistency, and more.

But the ones that focus on delivering value to the customer are always important. So rather than measuring how much you’re doing, or what you’re doing, it’s a good idea to ask yourself, are the KPIs we’re using serving to measure how our actions in the development process are impacting the customer? If not, it might be a good time to revisit the KPIs that you use and share with your customers.