What software project KPIs do customers really need?
Software project key performance indicators (KPIs) are something you need to hold your finger on your project health pulse. It is a great tool to early detect issues and find a solution to resolve them. Moreover, it is a good tool (though, not the only) to get a real picture of your vendor’s proficiency, reliability, and approach to their work on your project in numbers.
Despite there are many KPIs for a software development company, not all of them come down to a customer or have any value for them. So, let’s omit those that are unimportant to focus all your attention on those that really matter.
Team velocity
Let’s look at how a software development pipeline looks like:
- The project is divided into the tasks (it can be user stories to implement, features to build, tests to perform, etc.). To have more comparative and representative values, we recommend you negotiate and give some number of points to each story or task to implement.
- You estimate, negotiate, and set milestones for each task or a group of them (typically, this is about iteration we are speaking now).
- Your vendor starts working on your project, implementing these user stories and building some software functionality.
For you as a customer, it is important to know how fast your vendor succeeds in developing software for you. That is where team velocity arises as one of key performance indicators for a software development team. To go further with details, we recommend to measure two metrics here:
- Iteration team velocity
- Accumulated team velocity
Iteration team velocity
This metric often named simply as team velocity. It indicates how many features developers build during one iteration (we call it sprint in agile software development). You need to set team velocity values for each iteration and measure actually achieved values every time the sprint is over.
The best case here is as follows (for every iteration):
Planed team velocity = Actually achieved team velocity
However, to get really representative values, you need to follow some rules:
- Re-estimate team velocity with each project alteration (when you add new functionalities in the backlog, re-arrange tasks between sprint, etc.)
- Recalculate team velocity each time when actually achieved team velocity is lower than planned one (Not doing this, you are likely to always get low team velocity due to the delays in one of the previous iterations)
Accumulated team velocity
This metric is a derivative of the previous one as it is calculated using the values you set for team velocity per each iteration. Thus, you get numbers that increase with each iteration so that you can understand how close the end is and get a more precise date of project delivery.
The best case here is the following:
Planed accumulated team velocity = Actually achieved accumulated team velocity
However, calculating accumulated team velocity, you should re-estimate its value only when there are some changes regarding your project or rearranging tasks between sprints. Apart from team velocity per iteration, you don’t need to recalculate accumulated team velocity in a case when the team achieved lower velocity in a previous iteration. The logic here is a team can facilitate their efforts and catch up their sprint backlog during the next iteration.
Cycle time
Now, let’s look at how feature development is carried out. The development pipeline here is a cycle. First, developers build the functionality. Then, they test it to reveal bugs, including live tests. Third, they fix these bugs and integrate the feature into the solution.
However, this doesn’t mean the work on the feature finishes forever. On the contrary, other bugs can be found, some alterations and upgrades can be necessary further. In this case, new tickets get opened and your outsourced developers renew their work on the feature to evolve it or fix bugs they have omitted. To clarify, this is the fourth stage in feature development. And, depending on your developers’ accuracy as well as on other outside factors, there can be the fifth and even more stages.
Only when the feature is, at last, released in its final version, the cycle comes to its end.
So, if you sum all the man-hours your developers spend on building, testing, improving an exact product feature, you get another important KPI for your software development project, cycle time.
To dig further, cycle time splits into two components:
- Main time (the first three stages, after which a development team report they have done the user story and add certain story points to their score)
- Extra time (all the next stages during which their fix bugs and make further upgrades, if necessary)
The usefulness of this KPI metric is hard to overestimate for software development. First, it gives you an understanding of the exact numbers of man-hours that were actually required for building each of the targeted functionality. Thus, you can always compare the numbers you set initially and the numbers you get in reality. The best case here is as follows:
Really achieved cycle time = Initially set cycle time
Second, this metric helps you better understand your outsourced developers’ reliability and testing accuracy as well as get a real picture of their efficiency. To clarify, here we talk about analyzing the main time and extra time. The best case here is the following:
Cycle time = Main time
Of course, this KPI metric can be regarded as an informative for a fixed-price pricing model. However, it is of great significance for a time and material model where any increase in any cycle time component raises your expenditures.
Note, each time you face any deviation from the set values you set initially, investigate why this happened to get to the roots. In other words, not all deviations are the sign of poor performance of your outsourced software development team. There may be quite a good excuse as the reasons may lie on the project side as well.
At SOFTENQ, we do our best to ensure software development KPIs that benefit the project at their best. So, contact us and entrust us with your software project.
