产品所有者对产品应如何在复杂的业务流程工作流（批准和不批准）中支持用户有特定的要求。记录需求的最简单方法是以流程图/流程图的形式。
然而，在 Scrum 中，建议要求采用用户故事的形式。解决这个问题的最佳方法是什么？
选项 1 包含包含工作流的通用用户故事，并将流程图作为支持文档附加。例如，作为作者，我希望能够提交我的文章以供审批，以便发表。
优点 人们更容易理解和消化——而不是阅读 10-20 个用户故事。
缺点 它变成了史诗
选项 2将复杂的流程图分解为自己的用户故事。例如，作为作者，我希望能够提交我的文章。作为编辑，我希望在文章提交时收到通知，以便我对其进行审查。作为编辑，我需要批准一篇文章 作为编辑，我希望能够请求更多信息...
赞成 纯 Scrum。易于确定优先级/估计/计划
缺点 如您所见，即使是简短的业务流程工作流也很容易爆发成大量用户故事。
我同意 pma_。做有意义的事。在这种情况下，您有一些看起来很棒的用户故事。
“作为一名编辑，我希望在文章提交时收到通知，以便我对其进行审阅。”
如果你有很多这些，那么它们可能太小了。他们都是1-2小时。这可能不是一件好事。在这种情况下，请尝试将它们分组。也许“作为编辑，我希望能够管理文章”。这将包括您已经拥有的几个。
记住用户故事的目标......
如果你能实现这些目标，那你就很好。如果没有，请再试一次。
哦，还有最后一件事——保留流程图，不要为了故事而把它扔掉。但是用它来补充故事。
如果此业务工作流程与大多数业务工作流程一样，那么这些步骤中的每一个都将具有大量规则。这些规则应该映射到这些故事的验收标准，理想情况下，应该是自动化测试，以证明代码按预期工作。由于可能有很多验收标准，我倾向于第二种选择。
我倾向于在早期使用核心最终用户/利益相关者增值功能进行功能/史诗，例如在您的示例中“发布文章以便订阅者可以获得最新消息”。然后，一旦功能越来越接近实现，如果需要，我会将其拆分为实现大小的故事。
大多数重要的业务工作流程都受益于在实施过程中的拆分，以便可以持续部署和验证它们，以便从利益相关者那里获得早期反馈。将所有内容都作为一个大爆炸实现的一大缺点是后期验证。我认为获得早期反馈超过了处理多个故事所增加的管理负担。
关于如何将史诗拆分成故事的提示：Lasse Koskela 有一篇关于如何以不同方式拆分故事的精彩文章。
对我来说，所有敏捷都是关于使用常识。在这种情况下，你有完美的设计，所以只需实现一个，不要寻找不必要的东西。
我们目前正在构建基于业务流程的内容管理系统。我们根据您的第二个选项将我们的流程分成故事。
但是，当然，我们将流程图放在手边。事实上，我们把它打印出来贴在墙上。我们甚至保留了它的每个旧版本，因此我们将自己的基于纸质的版本控制贴在墙上（除了使用 git 作为电子版本 ;-) ）
然而，在 Scrum 中，建议要求采用用户故事的形式。解决这个问题的最佳方法是什么？
您提到的两个选项并不是真正的选项，它们是顺序阶段，恕我直言。在敏捷需求收集或产品规划期间，第一步是创建 EPIC 故事。拥有这些史诗之后，您需要将它们分解成更小的块。
如果没有 EPIC，您很可能会遇到创建随机故事的问题，而无法掌握故事的归属感。您可以在某种程度上在用户故事中创建层次结构。如果不理解这一点，一切都是随机的，因此它会让你更难绕开你的脑袋或将故事作为 PO 来管理。
当然，这一切比我在上一段中提到的要多得多。这就是为什么您可能需要一位经验丰富的 Scrum 教练，或者对敏捷规划和用户故事写作进行大量勤奋的阅读/实施。
希望这是有道理的。我建议任何甚至远程考虑担任 PO 角色的人阅读 Mike Cohn 的 Agile Estimating and Planning 。祝你好运！
工作流是编写用户故事和史诗的有趣入口，但用户故事不是映射到工作流程，它们映射到业务能力。所以你从一开始就在这个问题中加入了一些错误的想法。工作流是一个很好的对话工具，但将独立于工作流，因为它们关乎功能，而不是时间。时间存在于业务规则中。需要注意的是，业务规则不是验收标准，它们是验收标准（产品所有者可以展示的功能）和测试用例之间的联系。同样，验收标准是关于特征，而不是行为。行为存在于业务规则中。例如，我可能有一个 ATM 的用户故事，上面写着“作为用户，我可以检查我的帐户余额”。验收标准可能是“如果我透支，我会收到警报通知”。不是验收标准。它们是业务规则，其执行导致验收标准的可证明行为。请注意，此用户故事可以通过工作流分析捕获，但可能存在于许多工作流中（或没有）。