Technical debt vs technological debt
Hi,
another question for you. I've heard that someone told about technical debt. Next time other said technological debt. I must say, that I'm little confused, are they the same ? Or maybe there are some diffrences between them. Which naming is proper ?
Of course I know what is technical/technological :)
thank you in advance for your help
Technical debt may be understood as the longer term consequences of poor design decisions. I suspect a reference to technological debt may be more likely to refer to legacy estate for which there is a quantifiable cost to business
e.g. running costs, maintenance and upgrades, resourcing of skills, waste such as reliability and downtime costs, increasing SLA costs, evidence of missed opportunity cost.
Whatever is meant though, figure out if the debt has been estimated and whether reasoned decisions were made to incur it. If not, the so-called “debt” might just be a sugar term for unquantified and unmanaged losses.
Ian,
thank you for you anwser. Sounds very suitable :) I must say, that I've never thought about it like that, but it makes sense.
Of course I'm trying hard, to don't left any debts without inspection.
Where or how is technical debt recorded and monitored? Is it included in the product backlog? If it is on the backlog is it a user story? Thanks
Is it included in the product backlog?
The Product Backlog contains an ordered list of all the work needed to be done to the product.
Technical debt is work that is needed to be done to improve the product.
Where do you think technical debt should be recorded?
If it is on the backlog is it a user story?
If you utilize user stories to capture your product backlog items, then sure it could be an user story.
Having technical debt listed on the product backlog allows the Product Owner to order it appropriately in regards to other work. For example, if addressing a product backlog item related to technical debt could make it easier to introduce some new functionality, the Product Owner could chose to order it higher in the backlog.
Where or how is technical debt recorded and monitored? Is it included in the product backlog? If it is on the backlog is it a user story?
Yes, Technical Debt should be captured on the Product Backlog for transparency. Not all Product Backlog items must be described in a user story format. I've found that there is no value in describing technical debt PBIs in a user story. I usually ask the Developers to document it in whatever format works best for them.
Where or how is technical debt recorded and monitored?
It isn't: it is dealt with. The quality of the Product Increment has been compromised and the Developers, for whatever reason, have been remiss in their accountability for ensuring work is Done. The Definition of Done gives transparency over the requisite level of quality and allows it to be managed.
Is it included in the product backlog? If it is on the backlog is it a user story?
The Product Backlog should tell the truth at all times about how much work is currently believed to remain for the Product over its lifetime. That transparency ought to include visibility over any so-called "technical debt".
There's no prescription in Scrum about how the Product Backlog should be structured. There may or may not be any discrete items for technical debt and there may or may not be any user stories at all. What can be inferred is that the totality of the work captured there, including any technical debt, ought to be reflected in the Developers' sizing of that work.
I believe I have answered this before but please let me repeat.
In 2020 Scrum.org made an excellent release about Evidence Based Management, also explaining where to fit technical debt and all other metrics of team performance.
https://www.scrum.org/resources/evidence-based-management-guide