Software is different from tangible goods and it must be measured differently. The tasks that developers do are different from day to day, so we can’t directly measure productivity in any meaningful, normalized way. I often advise teams not to measure velocity because it can send the wrong message and give management the wrong goals. Velocity can be raised at the expense of quality, which is a mistake. Here are seven strategies for measuring value in software development.
1. Measure time-to-value
We produce software to fulfill some need or desire and the time from when we start creating something valuable to when it’s realized by users is a good measure of our effectiveness. Local optimizations are meaningless if they don’t help to optimize the whole process. Measuring time-to-value keeps us focused on the big picture—something worth measuring.
2. Measure time spent coding
Developers love to develop but things can get in our way. Ironically, the time spent assuring quality in many organizations robs teams of valuable time they could have used to actually create quality. I know developers who spend less than ten percent of their time developing. The rest of their time is taken up by meetings, reporting, and who knows what else that may not be contributing to the bottom line. A good development process is one where developers spend most of their time actually developing software.
3. Measure defect density
Most organizations track bugs but this can have an adverse effect of increasing bug tolerance. Defects in code are often a symptom of a deeper cause, a defect in the development process. If defects are consistently showing up in production code it means the development process may be broken. Look for the root cause and try to fix it. Defect density (bugs per thousand lines of code) is one of the few measurements that can be compared across teams and time so it can be used for process calibration.
4. Measure time to detect defects
It’s been shown that the cost of fixing defects increases exponentially as time elapses since the defect was created. The cheapest defects to fix are the ones that are detected and fixed immediately after creation. Finding defects faster not only decreases the cost of fixing them but also helps developers become aware of things they may be doing that allowed the defect to be created in the first place.
5. Measure customer value of features
Not all features are equally valuable to customers. In fact, nearly half of all features created in software are never used. We order our backlogs so the highest value features are created first, which lets less important features get put off or dropped. This gives us more time to focus on those higher value items. If you’re unsure of what features will provide the most value, ask your customer. If your customer isn’t sure what they want then give them something they don’t want and you’ll likely see them quickly get clear on what they do want.
6. Measure cost of not delivering features
We often look at the value of delivering a feature but sometimes the cost of not delivering a feature is the most compelling reason for building it. Ask your stakeholders how much the feature is worth and how much not having the feature will cost. The answer may surprise you.
7. Measure efficiency of feedback loops
The most powerful point of leverage for increasing efficiency is often in the process itself. A good development process has built in feedback loops that can be used to tweak the process. The faster the feedback the more efficient we can become. Find ways to fail fast and learn from failure. This is how teams rapidly improve.
Most teams who try to measure productivity end up sacrificing quality. Measuring productivity may not be possible and can certainly be disruptive. Instead, focus on producing and measuring value, both in the product delivered and in the process used to create it.
Previous Post: « Seven Strategies for What to Refactor
Next Post: Seven Strategies for Burning Down Risk »