敏捷团队有时也会为纯技术性任务而挣扎，比如必须处理技术债。虽然这种任务对系统用户没有直接价值，但要交付可以工作的软件又不得不处理。那么，是不是应该创建用户故事来应对这样的技术性任务或技术债呢？
在博文《像“作为开发者……”这样的表达并非用户故事》中，Bill Wake谈到了他所遇到的对客户没什么价值的用户故事。作为例子，他提到了“作为开发者，我想配置Jenkins，以便进行持续集成”这个用户故事。Bill解释了为什么我们不应将其称作用户故事：
我不是说这些活动不好，或者说不重要，它们也是面向这个团队的，不过将其当作用户故事会误导团队及其客户。把与用户无关的东西以用户故事的形式写下来，这是没抓住要领。
他的观点是，应该称其为任务，而非用户故事。根据精益思想，他认为这些活动其实是种浪费：
从精益思想的角度看，团队所做的很多活动都可以视作浪费，但我们又不知道如何避免这些活动从而有效地进行软件开发。精益团队称其为“不增加价值，却又必不可少”，因为这是不得已而为之的事。
Bill建议，如果某些用户故事的角色不是来自实际软件用户，而是来自于开发之中，这时一定要慎重。可以尝试将这样的用户故事重新组织为功能行为或 质量特性，然后换种描述方式；如果行不通，再考虑将其看作任务。作为任务，开发团队需要跟踪，但又不应将其作为用户故事放在产品Backlog上，因为它 们并不交付价值：
（……）承认你的团队有时面对的只是任务。可以内部跟踪这些任务，但是不要将其看作所开发系统的直接进展，更不要将其当作直接进展来跟踪。
关于如何在产品Backlog中处理技术性任务，Mattias Marschall在其博文《技术上很重要的事物，怎样表达出“业务价值”》中提出了一种方案。他首先解释了如何看待用户故事与技术性任务之间的关系：
用户任务应该描述用户想让系统做的事情。纯粹的技术性任务通常实现为用户故事的一部分。
但如何处理与具体的用户故事没有直接关联的技术性任务呢？Mattias建议把它们放到产品Backlog上：
要把技术性任务按优先级放到产品Backlog中，那就为每一项创建一个用户故事。等等，这不是弄虚作假吗？不，如果你能回答如下两个问题，那就不是：
- 谁能从其结果中受益？
- 为什么这个任务是必要的？
利用他的解决方案，我们既可以把所有的技术性任务包含到产品Backlog中的用户故事里去，也可以将其作为面向客户的用户故事的一部分，还可以使用一个专为技术性任务创建的用户故事来应对：
如果你能将技术性任务明确地表达为一种用户故事，那么利益相关者就能理解它们的必要性，并将它们与其他用户故事一起优先考虑。
Bastian Buch在其博客文章《减少技术债的有效步骤：敏捷方法》中解释道，对于与技术债相关的技术性任务，开发者和产品所有者可能有不同看法：
开发者了解技术债，也能意识到面对这种问题的重要性。
产品所有者往往不理解减少技术债的必要性和收益所在，因此他们不会考虑甚至不允许把技术性项目或用户故事列入他们的产品Backlog和发布计划中。
他建议由产品所有者负责减少技术债。团队成员应该与产品所有者讨论技术债，并共同努力，让技术债在产品Backlog中具有正确的优先级：
团队应该记住，产品所有者是团队的一分子，他的痛苦就是大家的痛苦，反之亦然。他不是团队的客户、买主或老板，而更像是来自不同利益相关者的主题专家（SME，subject matter expert）和产品需求管理者/分析员。
团队向产品所有者保证产品成长，这仍然是最重要的——不管从短期的绩效还是从长期的健康来看，都是如此。
Bastian建议把所有的技术性问题收集到用户故事中，评估投入和产出。他将收益称为“报酬”，因为解决了问题能减少技术债：
（……）针对我们定义的每一项任务，我们在JIRA中创建标记为“TechnicalDebtItems”的用户故事。为了安排这些项目的优先级并得出正确结论，我们创建一个图表来将投入与回报的相互关系可视化。
可视化有助于产品所有者和团队协作减少技术债。
通过将技术债和可能的回报可视化，（……）现在团队可以把精力集中在最重要的步骤上。还有一个重要的副作用：这也是与产品所有者和利益相关者协同工作的一个极好工具，因为它使技术债对他们也有很好的透明度。
chainding 