David Simner talks about some ways for measuring technical debt, and why it's important to choose the right ones in your team. He introduces the idea of story probing to see how fixing technical debt changes your scrum story estimates. See more at http://dev.red-gate.com/lightning-talks

1. Measuring
technical debt
(and why it matters)

2. You get what you measure
• We need to keep this in mind when
measuring technical debt, so that when
we make strides to pay back our
technical debt, that time investment is
actually worth it

3. Measurement approach 1:
The delta from ideal
• You define a whole bunch of metrics
where:
• You know what ideal looks like
• You know what reality looks like
• Then you see how you score

4. Metric 1
• C# compiler errors & warnings:
• Ideal = 0
• Reality =

5. Metric 2
• R# errors:
• Ideal = 0
• Reality =

6. Metric 3
• Amount of code duplication:
• Ideal = 0
• Reality = 58 exact matches, 75 strong
matches, 179 medium matches, and 191
weak matches

7. Metric 4
• Unit test coverage:
• Ideal = ?
• Reality =
• Better =

8. Metric 5
• Gut feeling:
• Ideal = amazing
• Reality =
• Unlike the previous 4, this can’t be
measured automatically
463 lines
8,999 lines
7,765 lines
4,725 lines

9. However…
• You need to pick the metrics carefully
• Otherwise there’ll be a high opportunity
cost to your fixing
• In a large application with lots of
technical debt, this measure is
basically useless
• There will be an insurmountable delta
between ideal and reality

10. Measurement approach 2:
Story probing
• Firstly, you need:
• A story
• Or, some stories
• They can be from the backlog
• Or, even hypothetical

11. Measurement approach 2:
Story probing (continued)
• Then, you estimate them
• Just as you Scrum has taught us to:
• 1, 2, 3, 5, 8, 13, 20

12. Measurement approach 2:
Story probing (finally)
• The assumption is that technical debt
increases the estimate
• You can re-estimate in the future, to
see if technical debt is getting worse
• Or, you can re-estimate after real or
hypothetical refactorings, to see if the
technical debt is actually reduced

13. Measurement approach 2:
Story probing (corollaries)
• One way to reduce the estimate (and
hence the technical debt) is to leave the
code alone (and therefore keep it in its
utterly terrible state), but to aid the
team’s understanding of the code

14. However…
• Imagine the estimate used to be 5
• After some refactoring, it’s now 3
• What does that mean in practice?
• What are the errors bars?
• Before: 5 ± 2
• After: 3 ± 2
• Is it actually any better…?