tfs - 锁定期望但未定义的行为：测试、验收标准还是用户故事？

我的团队正在使用 scrum 和 TFS 来管理一个新的软件项目。团队中的一些成员想以一种非常不寻常的方式解决问题。我需要知道是否有人处理过类似的事情。（这部分是一个 scrum/项目管理问题，部分是 TFS，因为如果 TFS 使一种方法比另一种更容易，那将影响决策。）

该软件系统的某些部分尚未以任何方式指定——不是通过用户故事、验收标准、测试或任何方式。它们在某种程度上是“极端案例”或错误处理案例。然而，当遇到这些情况时，软件已经以特定方式运行。（这可能是通过显示一般错误消息或沿着通用路径解决问题。）这种情况的存在是因为软件被设计为具有容错性。

团队成员想要定义并锁定未指定的行为，因此它不会改变。如果它确实发生了变化——特别是如果它变得更糟（例如，崩溃而不是显示一般的错误消息），他们想要抓住它。

但他们建议通过编写与系统在极端情况下已经完成的工作相匹配的测试或验收标准来做到这一点。我的立场是，我们想要保持稳定的任何当前未指定的行为都应该首先通过新的用户故事来定义，而不是通过验收标准或测试。什么是正确的 scrum/TFS 方法来记录和锁定现有软件主体中尚未指定的行为（最好用最少的努力）？

标签： tfsprocessscrum

这是系统用户将从中受益的东西，所以把它作为一个用户故事来做：

作为用户，我希望产品稳定，不会在发生特定行为时崩溃，从而获得良好的用户体验

为了满足这个用户故事，您可能会编写一个技术任务，导致测试与现有的边缘情况简单匹配。

为什么要费心把它变成一个用户故事？好吧，这个工作项目需要优先于其他积压项目，包括新功能。通过创建用户故事，我们允许使用标准 Scrum backlog 方法对其进行优先级排序。