April 20, 2017

...Learn TDD with Codemanship

20 Dev Metrics - 3. Dev Effort Breakdown

The third in my Twitter series 20 Dev Metrics is Development Effort Breakdown.



I've come across many, many organisations who have software and systems that, with each release, require more and more time fixing bugs instead of adding or changing features. Things can get so bad that some products end up with almost all the available time being spent on fixes, and users having to wait months or years for requested changes - if they ever come at all.

This can get very expensive, too. A company who made a call centre management product found themselves needing multiple teams maintaining multiple versions of the product that were in use, all devoting most of their time just to bug fixes.

I'm suggesting this metric instead of the classic "defects per thousand lines of code", because what matters most about bugs - after the trouble they cause end users - is how they soak up developer time, leaving less time to add value to the product.

To track this metric, teams need to record roughly how much time they've spent completing work (with the usual caveat about definitions of "done"). If you're using story cards, a simple system is for the developers to take a moment to record how many person-days/hours were spent on it on the card itself. Your project admin can then tot up the numbers in a spreadsheet.

Remember to include bugs reported in testing as well as production. If someone reported it, and someone had to fix it, then it counts.




Posted 5 months, 5 days ago on April 20, 2017