我总是听说用户故事应该非常简短和清晰，因此可以写在便条等上。比如“作为用户，我希望能够输入、修改和删除目录中的人”。
但是为了测试，我们需要知道：
这在 Scrum 中是如何解决的？
【问题讨论】：
标签： testing agile scrum user-stories
这通常由一个共同的完成定义来促进，每个 Scrum 团队成员在提交之前都必须达成一致。
用户故事接受标准应阐明用户故事中涉及的所有要求。产品负责人需要轻松验证此类标准以允许完成用户故事（例如，您可以在文本字段中输入多少个字符）。团队中的每个人都需要了解必须做什么，但在 Scrum 活动会议期间，您可能只使用用户故事标题。
将技术内容放入任务中（例如，用于存储字符串的 db 字段大小、其他技术假设等），不要打扰产品负责人和 QA 人员。
【讨论】：
SCRUM/Agile 的理念是专注于您编写的功能的商业价值，而不是在故事开始之前就迷失在详细的实施细节中。因此，建议是使故事信息尽可能简短。但是当故事被开发出来时，开发团队将创建/发现一些功能/技术限制，并与产品负责人核实他们是否可以，并将它们记录在您用来跟踪故事的任何系统中（另一个便利贴，或 Jira 中的评论）。然后，作为测试人员，您将获得更多信息来检查边界/范围等。现在一些其他信息，如“验证消息”可以留给常识。你真的想要规范吗？如果这对开发人员有意义，并且作为测试人员，您发现消息 OK，那么您就完成了。
【讨论】：
它们将成为验收标准的一部分。您可能应该让 PO 回答这些问题
【讨论】：