在敏捷中构建故事的最佳方式[关闭]

Question

故事： 作为业务分析师，我应该能够在报告中看到 4 个新列

估计：3 个故事点 1 个故事点是 20 小时 == 60 小时。

所以这个故事需要 2 周 1 个 sprint 才能完成一个人的这个故事。

问题是： 1]这是评估故事的正确方法吗？ 2]一个故事可以有多个人一起工作吗？ 3] 根据 JIRA 或其他敏捷工具中的指南，这个故事中的每个子任务可能需要每天 6 小时。只要故事在 60 小时内完成，我们为每个子任务分配多少小时是否重要？ 4] 在这种类型的估计中，这个故事可能会在燃尽图中长时间显示未决或尚未完成的状态，这是正确的吗？

构建这个故事以使客户获得最大利益的最佳方式是什么？

Answer 1

1. 故事点不是时间的度量，所以不是。当我们在一致的环境中拥有一致的团队时，故事点与时间有近似的相关性。然后相关性足够接近，我们可以说一个团队在 2 周之类的时间段内完成了一定数量的故事点。这是我们能得到的最具体的。任何单个积压项目都会有很大差异，无法进行时间点比较。这可能看起来令人沮丧，但它是专门为颠覆这种类型的时间估计而设计的。

2. 是的，当然。事实上，在大多数情况下，大多数团队都会发现多人处理待办事项中的一个项目是最有效的工作方式。

3. 这是一个非常好的经验法则。把它想象成“经验表明……”。除此之外，关于子任务没有真正的规则。他们在那里为团队服务或组织自己的工作。使它们与团队认为有用的一样大或小。您甚至根本不必使用它们。此外，对于前一点，子任务的估计值或实际值加起来实际上并不重要，而且没有任何内容表明您甚至需要估计它们。我工作过的大多数团队都发现估算子任务是一种浪费。

4. 是的，你是对的。需要数天才能完成的积压项目在全部完成之前不会烧毁。那是故意的。这源于长期的工作在大部分时间内“几乎完成”。通过将完成视为二元状态，它会激发在开始其他项目之前完成项目。

您还询问结构。用户故事是表达用户需求的一种方式。在您给出的示例中，我假设业务分析师是最终用户。我还假设这个用户故事严格描述了格式化现有数据的工作。最佳做法是在末尾添加一个“so that”，例如“以便我可以看到过去 4 个季度的趋势”。重要的是要记住，用户故事不是规范。它们是团队用来设计产品体验的叙述。如果这不是您想要的，Scrum 不需要您使用用户故事。