您如何处理Scrum中的相关故事？

在我目前工作的公司中，我们注意到有时有些故事是相互关联的（因为耦合太紧密）。这可能是因为它们属于相同的总体功能，或者它们是不同的功能，但是其中一些功能需要先完成才能继续下一个功能，依此类推。

在不停止迭代工作流程的情况下，如何处理这种情况？我们做错什么了吗？

这是一个很好的问题。理论上说用户故事应该是独立的，但是我从来没有完全实现。

我认为最重要的是传达依赖性，以便团队和产品负责人都知道这一点。这将迫使产品所有者重新定义用户故事，以便消除依赖关系（例如，通过合并用户故事），或者相应地定义业务优先级，从而首先实现主要用户故事。

根据优先级和采购订单决策，您可以在相同的sprint中实现它们两者，也可以在以后没有问题的情况下实现从属产品，因为主体已经完成。

最坏的情况是，如果A依赖于B，而B依赖于A。在这种情况下，用户故事很可能定义不正确，应该重写为A和B（大多是独立的或仅具有单向依赖），而C则依赖于A和B。

相应地计划它们。

将它们放在同一sprint中，并且由于在sprint积压中也优先考虑了用户故事，因此不会有任何问题。

由于您的团队参与了此活动，因此他们知道了相关性，因此您无需担心。他们是成年人，如果您向他们解释依赖关系（通常他们会向您解释），事情将会顺利进行。

在敏捷中，就像在瀑布中一样，一次只能做一件事。如果B需要A，通常在B之前先做A。这是常识。

依赖关系可能是您在水平而不是垂直通过系统切片故事时的一种嗅觉。特定功能的开发应涉及从修改数据库设计到用户界面的所有内容。如果发现您在系统结构的较低级别上花了所有精力在用户故事上，例如为数据库查找编写处理程序例程，那么您更有可能在故事之间创建依赖关系。而且，您可能将用户故事写错了。

最好的选择是将独立的用户故事分解成较小的部分，使其尽可能独立。他们应该处理最依赖的故事（就像您说的那样：那些需要先完成才能继续其他故事的故事）。创建类似依赖项的索引：如果故事3的辅助因素比故事1多，则应首先增加Story3。

如果您的依赖性导致过多的停顿，最好完全停止工作（是，在当前冲刺的中间），然后重新评估您的优先级用户案例并首先解决它们