我开始为我的游戏积压添加第一个用户故事。我的团队对我们想要创建的游戏有一个大致的了解，并且我们准备好收集顶级要求。你怎么做到这一点？我的意思是，例如，您可以从一个巨型史诗（顶级）开始，其内容是：“作为发布商，我想创建一个游戏，玩家必须喂食怪物，以便他们度过一段非常有趣的时间。”这是一个正确的起点吗？我们是否应该将这部史诗分成较小的用户故事，并将这些用户故事分成较小的用户故事和最终的任务？这种“像树一样”收集需求的方式是好的，还是通常采用“平坦”的方式？如何管理在游戏中应用Scrum时写出第一个故事？
在此先感谢。
写好用户故事的一个很好的起点是the book by Mike Cohn。网上还有大量有用的资源，如何编写好的用户故事，以及如何与作为产品负责人的积压工作以及如何让团队参与，以持续保持积压状态良好，以便您可以进行有效的冲刺计划会话，做到合理预测功能可用时的日期等。
保持实用和实验总是很重要的。开始与东西，然后检查&适应，以便您改善。这是任何敏捷工具/框架的本质。
如果你愿意，从大史诗开始，看看如何。
也许不值得拥有这部史诗，而是讨论他游戏的玩家可以做的更具体的各种事情。这些东西是用户故事，即在整个产品中增加用户价值的东西。系统的垂直切片。
一些虚构的例子来说明各地的故事的想法在游戏设置：
是的，你可以看到它是一棵树或更多，更具体的故事，是其他故事或史诗的孩子。实际上，你只关心叶子，因为这是作为团队和PO在一起工作的产物，用于在冲刺计划或其他会话期间处理待办事项。
实验并从一些东西开始并从那里改进。
这就是我们所做的。从相当高级别的史诗开始，将它们分解成更多技术用户故事。通常我们停止在一个层次上，但有时候用户故事太大了，它需要分成更小的块。
在顶层是史诗，正下方是用户故事，就是这样。它可能会帮助你进一步分解为一个分解练习 - 但是建立一个庞大的依赖故事树可能需要很多追踪。我们试图捕捉利益相关者的需求和史诗（可以，可以有一些重叠，但没关系）。我们倾向于希望我们的用户故事成为“轻量级需求”。开发人员可以根据需要自由创建尽可能多的任务来完成故事。如果开发者发现任务太多，我们会回过头来看看我们是否可以打破这个故事。
我们的产品负责人管理“功能积压”，这只是说“史诗”的奇特方式。我们将特色故事与我们的团队故事联系起来。没有一个顶级史诗，有许多顶级史诗代表功能需求。通过这种方式，我们可以将功能逻辑分组在一起，以实现“发布”。
您可能想看看Jeff Patton的一种叫做“User Story Mapping”的技术。
“作为一个出版商我想创建一个游戏，让他们度过了一个非常有趣的时间，玩家必须养活一个怪物”
东西要记住的是，故事是从这个角度写的系统用户。在你提到的例子中，我发现发布者肯定是该项目的利益相关者，但不是用户（除非你创建了一个应用程序来生成游戏）。您的游戏用户。可能“玩家”将是主角，但你可以想到不同类型的玩家：高级玩家与新手，PC玩家与游戏控制台玩家，想要探索的玩家以及快速完成游戏的玩家等。建议您提供游戏需要支持的不同功能。
自上而下以树状方式进行需求收集对我来说似乎非常逻辑。我注意到的另一件事是，在不同的树级别（当你沿着树下，用户故事更具体），不同的角色将会出现，解释他们想要或需要完成的大图（树的根） 。当你向下移动树时，你会发现更多表达他们需求的技术角色。正如我所说，我刚开始并试图分享我的观点，看看敏捷大师是否可以证实或否认我的想法:)。 – Notbad
您不会为发布商制作游戏，您可以为玩家制作游戏 –