What about Technical Debt - is that a discrete unit of value, a flow item or both?

Following on from my last discussion post  - what about technical debt? Can we say that has value? Do we need it to flow?

If we look to model technical debt within ValueEdge I can see two ways to do this

i) We have a single technical debt feature per release

ii) We have several technical debt features pre release

If we take the first option - having a single technical debt feature makes it very visible, when we identify technical debt relevant to the release we simply add the story or defect to this feature. This feature could get large so it wouldn't make sense to track this feature as a flow item but you could measure progress by seeing how many stories within it were completed. Of course, additional stories could arise from an unplanned issue - but this could happen whether or not we decide to track technical debt in this way.

If we decide on the second option then we need to be careful that these technical debt features stay visible as what they are. We don't want to confuse them with Business features, they are a different type of flow item. Assuming we can do that then the next challenge is keeping the features to stay relevant, as well as keeping the technical debt visible we also need to make sure that the feature names reflect the nature of the technical debt - otherwise we may as well adopt option (i) from the start.

Choose an option and stay consistent with that, what we need to avoid is hiding technical debt away within Business features. This is where the technical debt becomes less visible and starts to inflate our Business feature estimates. Don't hide technical debt(!) Keep it visible and manage it separately to the Business features, see my post on technical debt here

Labels:

ValueEdge Functional Test