Working with startups, I've found a third type of "debt" to be common: Situations where you ship a MVP type feature, knowing that it's not fully baked - cutting corners for the sake of meeting a deadline. Usually this is something innocuous done with full visibility - something like deferring work on an administrative tool or support for a less-used option. In the moment it's always justifiable in the name of making that next big sale, but it's easy to forget (or the business forgets) and those items pile up. Because the urgency of "meet that deadline" is gone, the nontechnical driver for the feature is gone as well. I wouldn't categorize those as technical debt (although you could make a case for it) and they may certainly end up as bugs at some point. How do you recommend those items be categorized and measured, as techdebt or bugs or something different?
I can't find the original link now, but the best recommendation I've seen for that type of "we cut corners to get something out the door" tech debt is to fix it immediately after the project ships. Next best would be to create an tech debt backlog ticket every time you do that with an estimate of how much effort it would be to fix.
You're right that it would eventually manifest in the form of slower development or more bugs, but it's better to proactively track tech debt you know about rather than wait for downstream effects. In this case, you'd have to use your judgment about what's worth fixing since the costs would be more in the future than ongoing.
Yes, the particular situation I'm thinking of (and lived through) was a situation where we were simply understaffed given the breadth of "stuff" to manage, so if something didn't get done on initial release it almost never did. No amount of recategorizing can fix that (but visibility might help you make the case for more resources).
Working with startups, I've found a third type of "debt" to be common: Situations where you ship a MVP type feature, knowing that it's not fully baked - cutting corners for the sake of meeting a deadline. Usually this is something innocuous done with full visibility - something like deferring work on an administrative tool or support for a less-used option. In the moment it's always justifiable in the name of making that next big sale, but it's easy to forget (or the business forgets) and those items pile up. Because the urgency of "meet that deadline" is gone, the nontechnical driver for the feature is gone as well. I wouldn't categorize those as technical debt (although you could make a case for it) and they may certainly end up as bugs at some point. How do you recommend those items be categorized and measured, as techdebt or bugs or something different?
I can't find the original link now, but the best recommendation I've seen for that type of "we cut corners to get something out the door" tech debt is to fix it immediately after the project ships. Next best would be to create an tech debt backlog ticket every time you do that with an estimate of how much effort it would be to fix.
You're right that it would eventually manifest in the form of slower development or more bugs, but it's better to proactively track tech debt you know about rather than wait for downstream effects. In this case, you'd have to use your judgment about what's worth fixing since the costs would be more in the future than ongoing.
Yes, the particular situation I'm thinking of (and lived through) was a situation where we were simply understaffed given the breadth of "stuff" to manage, so if something didn't get done on initial release it almost never did. No amount of recategorizing can fix that (but visibility might help you make the case for more resources).