所以我们今天开始Scrum并开始讨论故事点估计。
出现的第一个故事是需要开发的新屏幕。它有1个句子来描述屏幕和3个用户验收测试。
这开始了开发团队和产品所有者之间的斗争。
产品所有者表示不需要编写故事，并且在冲刺期间它们只会被充实。
我们说这个故事需要完全用于冲刺。
但现在我开始不确定谁是对的......
我可以向团队发送关于如何定义用户故事的任何好文章吗？
答案 0 :(得分：4)
sprint计划期间发生了什么？
您似乎没有在启动冲刺之前查看sprint计划以查看故事。
没关系。
在冲刺期间，的故事充实了。这才是重点。放松。
快速充实故事，快速建立。
在某些时候，一句话的故事可能变得相当复杂。如果是这种情况，请将其分解为 在冲刺期间完成的内容，以及不会完成的内容。可以使用一些未知且未构建的东西。
放松。
不要过度指定一切。在冲刺之前不要指出故事的每个细微差别。只需构建一些有用的东西。尽快。这就是为什么它被称为“冲刺”。
不要构建你想象的一切。足够构建，以便用户可以执行故事。
重点是按计划构建工作的东西。如果你必须调整故事的范围，那没关系。
答案 1 :(得分：1)
我可以向团队发送关于如何定义用户故事的任何好文章吗？
故事通常基于以下模板由一个句子组成：按顺序到＆lt; benefits＆gt;，作为＆lt; role＆gt; 我想要＆lt; action＆gt; （我想添加“如何演示”步骤，以帮助理解故事并构建验收测试）。这个想法是捕捉本质，而不是细节。在冲刺期间使用面对面会话捕获细节（并且可以作为故事的高级笔记添加）。但是用户故事不是契约，而是对话的承诺（关于故事作为标题的场景）。如果您需要一些指导原则，遵循INVEST模型对我们来说效果很好。
PS：没有冒犯，但开发团队似乎反应非常具有防御性（要求完全拼写的东西听起来像“嘿，我们按照它写的那样做了”，即CYA）。用户故事为创造力留下了一些空间。不是很好吗？如果您需要更多细节，请承担责任，去收集它们。如果出于任何原因，您无法获得必要的说明或细节，请设置障碍并让您的ScrumMaster工作。就个人而言，我喜欢有一些创造空间。答案 2 :(得分：1)
恕我直言的斗争并不好 - 产品负责人，Scrum Master和开发团队组成 Scrum团队，因此他们需要共同努力。他们希望实现同样的目标 - 建立一个伟大的产品。
对我来说，问题是产品负责人对最终结果的重要性。如果他说：“我们聘请了市场上最优秀的人，你就是专家，只要用户需要得到满足，无论你提出什么都没关系”，那么我对PO声明很满意。但他当然不能抱怨他不喜欢这种颜色或颜色！
另一点是，团队需要确信他们可以承诺这个故事。通常团队通过计划扑克估计故事大小，因此如果开发团队无法估计，您需要在此之前投入时间来估算（例如，之前谈论故事，尖峰并与PO就故事进行协商）。有时，设计师/ UX人员需要提前工作并为即将到来的用户故事创建模型。
总是要在计划和行动之间找到平衡： - ）
FS
答案 3 :(得分：1)
我相信Martin Fowler在Conversational Stories上的博文可能最能回答你的问题。您真的不希望产品所有者需要详细说明所有内容。您拥有一支聪明，富有创造力的团队，他们完全有能力提出良好的实施建议，并在冲刺期间提出正确的问题。你不想通过预先锁定需求而失去创造力和投入。
这个故事应该足够清楚，团队了解这个功能是什么，并且足够小，团队可以在将其添加到sprint backlog之前在一个sprint中完成它。其余的细节应该在冲刺期间通过对话来处理。
答案 4 :(得分：1)
在我们的实践中，我们会在与利益相关者进行规划之前对下一个春季的门票进行内部调查。我们通常会发现很多问题需要澄清。如果我们在冲刺开始之前没有回答，我们无法估计它。如果我们在冲刺期间发现了新的问题/问题，我们会通知利益相关者，通常这样的故事将被转移到下一张票。
所以，我的回答是：这个故事不需要完全用于冲刺。但团队需要知道实施所需问题的所有答案以及业务决策。