Computerworld - Most of us track faults (also called defects, problems, issues, bugs) during the system test part of the project. However, many project managers don't track how many of our fixes are successful and how many fixes are bad -- either introducing a new defect or not completely fixing the original defect. If you're looking for better scheduling of your system test and project completion, start measuring your Fault Feedback Ratio, the FFR.
Here's how to calculate your fault feedback ratio:
|Fault Feedback Ratio =||Fixes that require more work|
|All the fixes|
When I've measured successful projects, the FFR stays under 10% throughout the project, meaning that no more than one in 10 fixes are problematic as the work progresses. (Don't be deceived by a low FFR and a high overall fault count. With a large total count, the defects can be too overwhelming to successfully manage.) A low FFR and a not-too-high overall defect count also implies that the developers have a relatively easy time finding and fixing the problems. The testers don't have too much trouble keeping up with testing the fixes, because the fixes haven't broken other pieces of the software. The project team is progressing.
On the other hand, an FFR of 15% or higher means that people are spending significant time finding and fixing problems. A higher FFR and a low defect count may mean that the problematic fixes are in the same part of the code base. A higher FFR and normal or high defect counts, may mean the developers may have trouble detecting where to fix the problems, and the testers may have trouble verifying the fixes are good.
Once the FFR hits 20%, you're making dubious progress on the project because your team is spending too much time re-fixing problems they thought were already fixed and retesting those fixes.
|Johanna Rothman consults on managing high technology product development, focusing on project management, risk management and people management.|
Join the online discussion about this column.
By the time the project was supposed to start system test, the FFR was up to 23%. The project had met its previous milestones, but the team was unable to predict the start of system test. Their previous progress
- DevOps meets ALM in the Cloud - Cloud DevOps PaaS To improve software delivery performance and effectiveness, teams need automation, governance, architecture best practices, and increased team collaboration. Find out more.
- Coding with JRebel: Java Forever Changed With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with...
- What Developers Want: The End of Application Redeploys Eliminate application restarts in Java with JRebel! JRebel is a JVM plugin that eliminates application redeploys from the Java development cycle, a process...
- How a German energy company saved 1 day per week of development time with JRebel Check out the following case study to see how Heliocentris, a global energy supply and efficiency company deployed a development solution that was...
- It's not too late...Get Your Mobile Questions Answered Live! How can IT provide seamless and secure mobile communications and collaboration for all? Join this live Webcast as IDG asks an expert panel...
- Why do you need an enterprise mobile platform? Today companies must offer great apps that run on a range of devices, and connect to an exploding set of backend data. Appcelerator... All App Development White Papers | Webcasts