scrum和规范

因此，我们今天开始Scrum，并开始回顾故事点估计

第一个故事是一个需要开发的新屏幕。它有一句话来描述屏幕和3个用户验收测试

这将在开发团队和产品所有者之间引发一场斗争

产品负责人说，故事不需要详细说明，它们只需要在sprint期间充实起来

我们说，这个故事需要为sprint完全细化

但现在我开始不确定谁是对的

---

我可以向团队发送关于如何定义用户故事的好文章吗？

在sprint规划期间发生了什么

在开始sprint之前，您似乎没有查看sprint计划以查看故事

没关系

故事在冲刺过程中变得丰富多彩。这就是重点。放松

快速充实故事，快速构建

在某种程度上，一句话的故事可能变得相当复杂。如果是这样的话，把它分解成你将在冲刺中完成的东西，以及你不会完成的东西。有一些不知道也没有建造的东西是可以的

放松

不要把每件事都说得太详细。不要在冲刺之前详细说明故事的每一个细微差别。只要做些有用的东西。尽快。这就是为什么它被称为“冲刺”

不要建立你想象的一切。构建足以让用户执行故事的内容

关键是要建立一个能按时工作的东西。如果你必须调整故事的范围，那没关系

我可以向团队发送关于如何定义用户故事的好文章吗

一个故事通常由一句基于以下模板的句子组成：为了为了，作为一个我想要的模型对我们很有效

---

PS：无意冒犯，但开发团队的反应似乎非常防御（要求提供完整规格的东西听起来像“嘿，我们照写的做了”，即CYA）。用户故事为创造力留下了一些空间。那不是很好吗？如果你需要更多的细节，承担你的责任，去收集它们。如果出于任何原因，你不能得到必要的澄清或细节，提出一个障碍，让你的ScrumMaster来解决。就我个人而言，我喜欢有一些创造力的空间。

我认为战斗并不好-产品负责人、Scrum大师和开发团队组成了Scrum团队，因此他们需要合作。他们想要实现同样的目标——打造一款伟大的产品

对我来说，问题是对产品所有者来说，最终结果如何是多么重要。如果他说：“我们雇佣了市场上最好的人，你是专家，只要用户的需求得到满足，你提出的任何建议都可以满足我的要求”，那么我对PO声明表示满意。当然，事后他不能抱怨他不喜欢它的外观或颜色

另一点是，团队需要有信心，他们可以致力于这个故事。通常团队使用planing poker估计故事大小，因此如果开发团队无法估计，您需要在估计之前投入时间（例如，在之前谈论故事、扣球并与PO协商故事）。有时候，设计师/用户体验人员需要提前工作，为即将到来的用户故事创建模型

总是要在计划和行动之间找到平衡：-）

---

fs

我相信Martin Fowler关于的博客文章可能最能回答您的问题。你真的不想处于这样一种情况：产品负责人需要详细说明每件事。你有一个聪明、有创造力的团队，他们完全有能力提出良好的实施建议，并在冲刺过程中提出正确的问题。你不想因为提前锁定需求而失去创造力和投入

---

这个故事应该足够清晰，团队能够理解这个特性是什么，并且足够小，团队可以在一个sprint中完成它，然后再将它添加到sprint backlog中。剩下的细节应该在冲刺期间通过对话来处理。

在我们的实践中，我们在与利益相关者计划之前，会对明年春天的门票进行内部调查。我们通常会发现很多问题需要澄清。如果我们在冲刺开始前没有回答，我们就无法估计它。如果我们在sprint期间发现新的问题，我们会通知利益相关者，通常这些故事会被转移到下一张票上

---

所以，我的答案是：这个故事不需要为sprint完全指定。但团队需要知道实施和业务决策所需问题的所有答案

我投票结束这个问题，因为它与编程无关。