Answers:
它们实际上不是用户故事。他们是利益相关者的故事。除非该软件实际上是由用户直接付费购买的，否则很少有故事完全是为了他们的利益而创建的。
我举几个例子：
实际上，大多数技术案例都可以带来商业利益，但对于用户而言却很少。用不同的方式对它们进行措辞会有所帮助。我通常使用Chris Matts的功能注入模板：
In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.
这明确认可了各种利益相关者，包括开发团队。现在，您也可以说出您的技术故事，并指出业务收益：
In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.
我为此写了几篇博客文章：它们不是用户故事，而是功能注入和处理技术故事。希望他们能帮上忙。
速度是衡量团队完成有用工作的能力的指标（与Drag相对）。通过长期提高团队效率，基础架构任务仍然可以间接地为最终用户带来价值。我毫无疑问地将这些事情作为用户故事进行跟踪（在这种情况下，用户就是开发团队）并适当地确定它们的优先级。与客户保持良好沟通的产品负责人应该能够确定这些任务可以放在哪里，而不会影响交付成果。
逐步做。
如果没有利益相关者想要它，那就不要讲故事了。只需一点一点地照顾它。例如，第一次手动部署。第二次，您将其自动化。第三次，您可以实现更多自动化。最终，您的构建不是最大的问题，因此您将重点放在其他方面。
在一开始，您将有更多这些以开发人员为中心的任务，这很好。您的速度（按故事衡量）将更低。这是对情况的正确表示。但是您总会拥有一些东西，因此对于团队来说，养成做必要的事情以改进流程的习惯非常重要。
恕我直言，理想的方法是将基础架构的工作作为任务，在它首先具有价值的用户故事下进行；正如您所提到的。
以你为榜样；手动构建和部署意味着这是一项持续的工作，没有完成的形式。它无限期地存在。
对于使以前手动完成的典型应用程序中的任何工作自动化的代码，也可以这样说。将这种努力定义为用户故事下的任务就可以定义完成；从本质上来说，这对最终用户具有价值。
您当然可以构建和部署每个sprint的应用程序，但是那将成为日常任务的一部分，而这些任务不会通过积压工作进行正式跟踪，因此所有这些都变得毫无意义。
我从未将用户故事等同于必须交付最终用户价值。这可能很常见，但不是我们如何处理用户故事。有时，这些类型的任务被认为是高峰，但是我们也有常规的用户案例，其估计点与其他任何用户案例一样。
从我所看到的来看，许多基础设施都被认为是既定的。这包括以下内容：
我使用过的大多数方法都没有过多地关注它们。这些构成了我所谓的Release0。在开始开发之前，这些东西应该已经存在。一旦您开始处理故事，就可以跟踪这些方面的任何变化以改进流程。
尽管开发团队可能会提供意见，但大多数项目应由项目支持团队处理。跨多个项目标准化这些项目应该为组织带来可观的回报。
考虑以下：
Scrum团队在现有产品套件中添加了主要功能。
有必要根据工程最佳实践升级开发技术/工具/实用程序，使其保持最新状态。
提前将发布工作与此工作配合使用是有意义的，以便在发布过程中可以解决Sprints问题。
因为企业从这些项目中获得间接价值，所以我建议出于透明度的考虑，这些是产品待办事项（PBI）。
团队调整这些项目的大小，并像对待任何PBI一样对待它们。
对我来说，这个问题归结为以下事实：我不想浪费时间试图找出如何将这项工作隐藏为其他以业务为中心的PBI之下的任务。
我不希望此类基础结构工作影响PBI规模。我想看看正在做什么，并了解我要支付的费用。
我还认为，通过投资于交付高质量解决方案所需的基础架构，使团队了解业务做出的承诺是有价值的。
XP 建议建议在所有工具和基础结构都已设置的位置进行“零迭代”。为这些故事编写故事是可选的，但可能是一个好主意。能够测试您的基础架构（增量构建，自动化测试和部署，通知等）是有益的
在我们的团队中，我们执行以下操作：
步骤2是最重要的。与敏捷实践一样，在Scrum中，您尝试完成任务的次数尽可能少。用它来避免浪费时间从事不必要的工作：我的经验表明，从长远来看，多达50％的“本来就很酷”的东西最终会被遗弃和维持。