产品所有者对产品应如何在复杂的业务流程工作流(批准和不批准)中支持用户有特定的要求。记录需求的最简单方法是以流程图/流程图的形式。
然而,在 Scrum 中,建议要求采用用户故事的形式。解决这个问题的最佳方法是什么?
选项 1 包含包含工作流的通用用户故事,并将流程图作为支持文档附加。例如,作为作者,我希望能够提交我的文章以供审批,以便发表。
优点 人们更容易理解和消化——而不是阅读 10-20 个用户故事。
缺点 它变成了史诗
选项 2将复杂的流程图分解为自己的用户故事。例如,作为作者,我希望能够提交我的文章。作为编辑,我希望在文章提交时收到通知,以便我对其进行审查。作为编辑,我需要批准一篇文章 作为编辑,我希望能够请求更多信息...
赞成 纯 Scrum。易于确定优先级/估计/计划
缺点 如您所见,即使是简短的业务流程工作流也很容易爆发成大量用户故事。