西安vi设计公司曾经要解决的最早的挑战之一是正确处置死者。典型情况如下。我的团队会将用户故事计划到他们的Sprint待办事项列表中，然后在Sprint期间对其进行处理。相应的值将投入增量中。换句话说，将创建发行质量的增量，例如达到团队的“完成的定义”，然后将那些计划的故事从剩余工作范围中删除。

问题在于，由于增量发布获得的经验有时会发现其中一些故事是不正确的或不适当的。当然，这完全可以从敏捷的工作方式中获得。每个版本都是检查和修改产品的机会。但是，对于将相关的用户故事委托给历史的团队，这也可能会产生问题，或者至少是一个问题。然后如何修改这些故事以正确地获取最新的理解，从而可以做进一步的工作并改进产品？这是西安vi设计公司的团队陷入的困境，他们向我求助。简而言之，他们希望我把用户故事从坟墓中带回来。

那时，西安vi设计公司还不太了解，用户故事对于他们所开发的Sprint仅“有效”。请记住，用户故事是有关可能需求的对话的占位符。这些对话在执行故事的Sprint期间进行。时间框结束且故事结束后，其中的对话占位符确实是历史。

如果一个故事在退役后被发现是“错误的”（即使只是一个或两个不同的验收标准而已被确定），那么这些发现就与一个新的故事有关。换句话说，我们将有一个新的占位符，用于以后有关所需范围的一次或多次对话，并且必须对此工作进行估计并在产品待办事项列表中进行说明。新的用户故事可能与早期的此类占位符非常相似，但这仍然是一个新的故事。

当然，如果原始故事的接受标准实际上没有得到满足，那么故事一开始就永远不会完成。它应该保留在产品待办事项列表中，并重新估算完成工作所需的工作。

有时，西安vi设计公司会在出现新需求时陷入用户故事“破裂”的困境。要记住的是，用户故事实际上并不能中断。对话将有希望发生，并且故事将在时间表结束时满足其接受标准并满足“完成的定义”，否则将不会。Sprint期间故事所代表的对话不会因将来的发现而中断，因此占位符本身也不会中断。这些古老的对话都无法超越过去，无法进入未来的时间范围，而在这些时间范围内它们会被撤销和破坏。希望“破裂”的是该故事的某些产品，例如从旧的验收标准得出的不推荐使用的回归测试。

完全有理由认为，验收测试将需要进行更改（就像系统本身需要进行更改一样），以适应西安vi设计公司因敏捷开发和交付而出现的新对话和新故事。但是，“考虑对旧故事的影响”是不合理的。没有影响。有可能是对他们的产品，如外接老验收标准BDD测试产生影响，但这应该由考虑系统新的故事来解决的，是和剩余的工作。通过有新的对话和新的故事来代表他们，可以实现这一点。