我们正在将我们的门户P与另一个第三方Web应用程序W集成。W 将显示在我们的门户中的模式弹出窗口中。
一个明显的用户故事（我们称之为US1）
作为用户 U 单击按钮 B 时，W 应显示为弹出窗口，并且应预先填充某些信息集"IS"，以便我可以查看信息集"IS"。
现在，为了预填充信息集 IS，我们需要创建一组 API 并在后端集成，以将信息从门户 P 发送到 Web 应用程序 W。
我的问题是，API 的创建应该是系统用户故事还是任务？
这项工作可以在冲刺中完成，但 API 创建和集成可能会完成多项任务。此外，完成此集成会阻止第三方 Web 应用程序中的后续用户故事。
那么我应该写一个系统用户故事（我们称之为SUS1）和这样的任务吗？
作为门户P，我应该能够将信息集IS发送到第三方Web应用程序W，以便用户可以查看此信息。
这显然需要创建子任务T，例如
"创建 API A"
或者我应该只为用户故事 US1 创建一个子任务 T。
这里的团队更习惯于将所有内容称为故事，以便他们可以轻松地在冲刺 （sprint） 中查看其活动，尤其是沟通并显示后续用户情景 US2 依赖于系统用户情景 SUS1。
API 的创建是一个基础设施问题，在利益相关者（或最终用户）级别上不应该可见。因此，您应该创建一个任务作为实现用户故事 US1 的方法。
但！
您应该垂直对系统进行分区，即该任务应要求实现不超过使 US1 工作所需的 API。您应该在实现后续用户情景的同时实现 API 的其余部分。
一个自然的结果是，增量构建的 API 将没有最好的设计。因此，在每一步中，您都应该考虑到到目前为止实现的所有用户故事进行重构。这比BDUF（Big Design Up Front）要好得多。
用户故事是从最终用户的角度编写的，并描述了他们希望从产品中获得什么。它们没有描述如何完成实施。
您描述的不是用户故事，而是几个实现任务的组合。
用户情景的示例可能是：
作为门户用户，我希望查看今天的天气信息，以便了解今天的天气
情况
一旦这个用户故事被分配给冲刺，开发团队很可能会将其分解为许多技术任务。这将包括创建一个足以交付用户故事的 API。