应该何时将用户故事组合并分开？

Question

作为一个学校项目，我们正在推出我们最初的一组用户故事。用户故事是否应记录用户的原始想法，而不将它们组合或分开？

例如，约翰补充说“我想发布多项选择问题。”，迈克补充说：“除了多个问题，我想发布真假问题。”大卫补充说：“在添加问题之前，我想要一个确认框”

你是否保留这3个用户故事，或者你想把John和Mike的结合起来作为“我想发布多项选择和真/假问题”。在这个新的用户故事中，有一个细节，比如“在点击添加按钮之前显示一个构造框”？

你选择什么？

Answer 1

来自用户故事应用书（Mike Cohn），他谈到了应该具有以下特征的“好用户故事”：

I.N.V.E.S.T（独立，面议，有价值，可估计，小，可测试）

您的问题属于“独立”特征。将OR分开的原因取决于如何使它们“独立”。

拆分/分离故事卡的原因

• 故事大于一个冲刺
• 故事结合高优先级和低优先级子故事

组合故事卡的原因

• 当我们看到他们有“依赖”时。在合并之后，实施起来不会超过5天。
• 合并后需要5天以上，你应该找到另一种分裂故事的方法。

关于你的例子：

1. 我想发布多项选择题。
2. 我想发布真/假问题。
3. 在点击添加按钮
之前显示一个构造框

在我看来，我会将它们留作3个故事，因为它们看起来是独立的。即使是“确认框”，您也可以只使用添加按钮的框来实现，该按钮可以显示警告框，无需任何问题。其中三个看起来很有价值且独立。无论如何，产品负责人或客户可以告诉您这些故事是否对他们有价值。因此，在拆分或合并后，您必须与产品负责人确认，以确保故事仍然正确。

Answer 2

我同意纳蒂的观点，我会把它们留作独立故事。仅仅因为它们是相关的，并不意味着它们具有相同的业务优先级。

例如，客户完全有可能决定多项选择问题是最高优先级，然后是真假问题，但确认框的优先级如此之低，以至于它们不希望在预算中实施没有涵盖积压的所有故事。

仅凭这个原因，我会让他们保持独立，这样我才能在每个功能上捕获业务优先级。

但是，如果我注意到客户端总是将它们称为“一个故事”并将它们作为一个组进行优先排序，那么我可能会考虑为优先级目的制作一个组合故事，然后将其分解为多个子故事开发团队进行估算和交付。