谁编写验收标准?

谁编写验收标准?你甚至应该有接受标准吗?这是一个隐含的问题，因为它假设我们使用的是用户故事。在用户故事中，你通常会说，为了交付特定类型的价值，某些特定的角色想要或需要一些东西来这样做，然后你通常会列出你的接受标准。

如果这些东西都到位了，我会很高兴的。然后你可能会有一些非功能性的验收标准。它需要符合特定的国际标准，或者需要在特定的时间内执行该标准。验收标准非常有用，因为当团队处理工作项时，他们知道需要做什么工作来帮助交付。

实际上，您可以通过示例使用规范。“同样，在这种情况下，在特定的背景下，当某些事件发生时，这是我们所期望发生的”。行为驱动开发、自动验收测试、实例说明，这些都是使用“给定时”格式的很好方式。

这是一种写接受标准的好方法，但是谁写的呢?是做工作的人写的，而不是产品负责人。你以为是产品负责人干的?我希望产品负责人与客户、利益相关者合作，管理他们对不确定性的期望，帮助人们意识到他们的一些工作实际上可能永远不会发生。

也许这里有多个优先事项，我们需要根据我们下个月和下个季度的目标，在scrum的下一个冲刺年，来选择我们的战斗。所以实际上开发人员，在scrum中工作的人或者看板系统的成员他们会写这些东西。他们会制定接受标准。我更喜欢这样做，因为如果一个产品所有者，例如，正在编写这些带有验收标准的项目，可能会有来自开发人员或看板系统成员的行为，他们会说，“不，你不能把这个带进来，因为它还没有准备好”。

从我的角度来看，这是一种糟糕的行为，因为让工作做好准备的最后机会是在scrum中的冲刺计划和看板中的补充;真的没有必要由产品负责人或团队以外的人来编写这些项目。