技术债务型的story，可以放在产品backlog中，并分配给后面的sprint。

当敏捷团队在实践、预算与资源的限制下，主动将一个不理想的、效率低下的、不“讲究”的解决方案确定为合适的时候，就会产生技术债务。技术债务的增加，会令持续开发或维护现有系统的成本与工作量，变得非常之高。这时，PO应该策划一个针对技术债务的sprint，以提高代码的质量与此次发布的质量。

技术债务可以被用作一种设计方法，但这样的方法只是“权宜之计”。以长期的视角来看，偿还技术债务的成本高昂。因为在技术环境中，相同的工作在未来比在现在需要更长的时间、更高的成本。

业务团队可能喜欢技术债务，因为这样可以获得短期收益（比如快速上线）。可技术团队却一定讨厌技术债务，因为那是长期的折磨（不停的debug、打补丁）。这便是运用技术债务的挑战，作为“权宜之计”，它需要被慎重“权宜”的地方。

随着时间的推移，为了促进发展，我们必须提高自身的能力：量化技术债务、平衡业务需求与项目的技术需求。

CMMI技术解决方案中的特定目标1——选择产品组件解决方案，可以用来提高对技术债务引入与否的决策力。而利用决策分析与解决过程域中的标准且结构化的决策过程，将有助于团队作出事关主动降低代码质量的一致且适当的决策。

敏捷团队还可以利用项目策划中的实践，在未来的sprint和发布中，将消除技术债务作为user story进行策划与优先级排序。