Comments on: Agile Metrics http://www.scrumsense.com/coaching/metrics Scrum Coaching and Training Services Mon, 26 Apr 2010 06:13:33 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Carlo Kruger http://www.scrumsense.com/coaching/metrics/comment-page-1#comment-105 Carlo Kruger Tue, 11 Aug 2009 12:39:50 +0000 http://www.scrumsense.com/?p=463#comment-105 All of these are good metrics and easy to collect with one exception. I think Technical Debt is an important metric to track, but using only the story point value has two problems I can see. One, figuring out the story point value will be a difficult one since in most cases the true impact will only be felt by the development team (refactoring debt should have no impact on functionality). Planning poker-ing should mitigate some of this, my concern is that there "should" be no impact on the non-dev parts of the team. I mean you have a comprehensive automated regression suite which runs on check-in and hence the the test and analyst types can use this time to sharpen their pool playing skills. Two, it ignores the aspect of accumulating technical debt which is what the impact on the ability to deliver business value in the future will be. So I think it would be important to have the team estimate the 'Business Value or Risk' of the technical debt item. I would also tend to see the Technical Debt accumulated as a leading indicator of a drop in velocity of the team, and would try to forecast what that impact is, once you've accumulated some supporting data. All of these are good metrics and easy to collect with one exception. I think Technical Debt is an important metric to track, but using only the story point value has two problems I can see.

One, figuring out the story point value will be a difficult one since in most cases the true impact will only be felt by the development team (refactoring debt should have no impact on functionality). Planning poker-ing should mitigate some of this, my concern is that there “should” be no impact on the non-dev parts of the team. I mean you have a comprehensive automated regression suite which runs on check-in and hence the the test and analyst types can use this time to sharpen their pool playing skills.

Two, it ignores the aspect of accumulating technical debt which is what the impact on the ability to deliver business value in the future will be. So I think it would be important to have the team estimate the ‘Business Value or Risk’ of the technical debt item. I would also tend to see the Technical Debt accumulated as a leading indicator of a drop in velocity of the team, and would try to forecast what that impact is, once you’ve accumulated some supporting data.

]]>