This article is part of a series that will address what kind of KPIs a SaaS company needs to track to make sure all parts of the business are doing fine. The focus of the current post is on software development or the so called RnD department of the company. The article is intended primarily for development managers, project managers, team leads or other senior staff, but anyone who’s interested may check what we have to say. Let’s get rolling without further introductions.
Average Lead Time [days/hours]
One of the most important KPIs (if not the most important) to track when you develop software is your average lead time to production. In a perfect world this would mean the time it takes an idea to be converted to actual product and deployed to production. In reality lead time is usually calculated as the time between the moment you start working on an idea to its full realization (the time it spends waiting is ignored).
If you are able to quickly convert ideas or users’ feedback into actual product you will be a star and people will love you. On the contrary, if you are slow to deliver what your users are asking for, then you risk to lose them and make your competition happy. With that in mind, always track your lead times and try to improve them. It might be a good idea to classify your items into different classes so that metrics don’t get skewed; e.g. average lead time per size, per priority, per customer, etc.
Average Cycle Time [days/hours]
Cycle time is almost as important as the lead time, because the lead time is practically the sum of the cycle times of all sub-processes that form the entire process of delivering goods. Let’s explain that further. Suppose your entire process is “idea generation” -> “idea implementation” -> “feedback/testing” -> “deployment”. The time a task spends in each of the stages is called cycle time and the sum of all cycle times equals the lead time.
It’s easy to realize that reducing the cycle time of all stages will lead to reduced lead time in the end. Try to reduce cycle time as much as possible, but at the same time be careful not to create local sub-optimums – if “deployment” takes 10 days on average, but all other stages take only two, then reducing the cycle time of anything else besides the deployment phase will make things worse. In other words, be careful and optimize only where it makes sense.
Distribution of Effort [%]
What if you have the best lead and cycle times, but you only work on defects? This is obviously not acceptable and you should have a good idea of the time you spend working on value-adding activities vs. non-value adding ones. This is easily achievable with any of the tools like Kanbanize – just put a type on each ticket and then use the analytics module to review the data. The target is obvious: more features and less defects.
Number of Items in Progress [count]
The big amounts of work in progress are enemies of your productivity as a company. The greater number of items you work on at the same time the more context switches you make. The more context switches, the greater the cycle times and therefore the lead times. We’ve already explained that long lead times are bad, right?
Consider imposing WIP limits to your items in progress by adopting the Kanban method. This will reduce the stress and will improve the quality of your work. If you have WIP limits already make sure that you always keep them.
Number of Open Issues [count]
If you ship with known issues in your code things are bad. Having a dozen open issues is somewhat okay but deploying with tens of open issues or hundreds of them (God forbid) is something you MUST tackle right away. Poor quality will kill you in the long run and you should definitely take a closer look at the number of bugs in your software. Define a limit that must never be crossed and make sure to invest into fixing as many of the issues as you can (or makes sense).
Number of Customer-reported (open) Issues [count]
Customer issues must be your top priority. Period. If a customer suffers you are losing business and if you get too many complaints you will soon be looking for another job. Define the target of 0 and work towards it. It may not always be possible to have zero open defects, but 90% of the time it should be like that. Track it, optimize it, control it.
Number of Recurring Issues
If there is anything worse than a customer issue, it is a recurring customer issue. The customer has reported it, you have fixed it, the customer was happy for a month, but then that same nasty issue appeared. The customer is already asking herself “Do they know what they are doing at all?”. You MUST NEVER allow that. It will happen once in a while, but when it does, be dead serious about it and do whatever it takes to prevent it from happening again. Track the number of recurring issues and if it becomes higher than 0 per release you should do something about it (you must have an automated test about each such issue as the least precaution).
All KPIs should be reviewed on a regular basis, preferably weekly. If a KPI looks bad, act on it, don’t just wait to see if things go better by themselves. They won’t 🙂 Do whatever you can do to affect the numbers positively, experiment and track how your changes affect the status quo.
You have a comment? We would be glad to see your replies in the comments section below.