Importance of KVI in Agile Projects
Importance of KVI in Agile Projects
If you feel like your Key Performance Indicators are no longer cutting it, read on to learn about a new system of estimating value.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
More often than not you must have been through a phase in your Agile Software delivery life cycle, where people have questioned you about the KPI (Key Performance Indicators) and how you managed them. Well, they still exist - just the way "Scrum-Butt" also exists. Though the world has moved ahead, we realized that the questions posed by businesses are still the same (e.g. how to engage more customers, how to create better customer satisfaction, which segment needs to be pushed, how to deliver more with less etc. etc.) and hence we should still use the same age old KPIs. Dreadful - isn't it?So, it is high time that we wake up and realize that "Performance Indicators" don't necessarily deliver "Value." For example, if a team is delivering high (or huge) lines of codes, it doesn't necessarily mean they are delivering loads of business functionalities. From a different angle, if a team is not communicating the results of measurement and analysis activities to all relevant stakeholders, it doesn't necessarily mean they are not delivering value (perhaps they are just aiming at delivering a working piece of software)! And that is why the focus should shift to "Key Value Indicators," i.e. KVI.
What Is KVI?
As the name indicates, it stands for "Key Value Indicators." What does it mean actually? It simply refers to the parameters which, if measured, show how we are delivering better value our customers. For example, instead of measuring LoC (which doesn't add any value to the customer) within the KPI system, use "Build Stability" as a KVI (because a stable build indicates readiness for deployment, i.e. faster TTM). So, let's take an Agile Software Delivery Project for example. If we are working on this project, instead of measuring only the standard set of parameters like Burndown, Acceptance Ratio, etc., consider a holistic view and include items like:
Release Burn Down Chart
Sprint Burn Down Chart/Velocity
User Story Acceptance Ratio (i.e. committed SP vs accepted SP)
Build Quality Index
Agile Practice Maturity
So What Exactly Changed?
If you noticed, we are changing the name to shift the focus from using a measure to understand what is happening (i.e. KPI), to a direction of identifying a means of improving value creation (i.e. KVI) for our customers. This is, essentially, the whole purpose of Agile Software Delivery - isn't it?
|KVI||Key Value Areas||Objective|
|Release Burn Down||Forecast and Planning||Understand how to improve timeline.|
|Sprint Burn Down||Forecast and Planning||Understand how to improve timeline.|
|Story Acceptance Ratio||Forecast and Planning;
|How to improve communication and improve quality.|
|Build Quality||TTM (Time to Market)||Ensure stable build is available for quick release.|
|Release Frequency||TTM (Time to Market)
Quicker Feedback Loop
|Ensure integrated product could be released in quick intervals and customer feedback could be collected.|
KPIs tend to get used in a Command and Control environment. I have seen many instances where it is not the case and they have my absolute respect! But otherwise, we should look for KVIs, which are more meaningful to our customers.
At the end of the day, winners don't do different things,. they do things differently!
Opinions expressed by DZone contributors are their own.