Member-only story
Scrum explained: Technical debt vs undone work
“Let’s release it now”. Peter Product Owner says.
“But Peter, we haven’t tested it yet. We don’t know if it works with all the other Increments, we don’t know if the user would accept it, we haven't even done the regression test.” the developers reply concerned.
“Well,” Peter answers, “I think it looks good and the stakeholders demand it, so I’m releasing it right away.”
After releasing it, the functionality itself worked. But under the hood, there was a lot more to do to really finish the Increment to meet quality standards. Technical Debt was introduced into the product. Technically, this team could go to production. Yet, due to the limited transparency from the outside, they were setting themselves up for a large amount of rework. They continued to release features on top of this untested part. What essentially is being built, is a house of cards. If the bottom one folds, the entire thing collapses and you have to redo everything.
That’s no different with technical debt. You could go to production. But is it a good idea? I don’t think so. Sometimes it makes sense to introduce technical debt. In situations where you want to learn really quickly to verify assumptions, for instance. Keep in mind that this debt needs to be repaid asap, and most likely with some interest, too. Time consumed…
