在敏捷中构建故事的最佳方式

问题描述

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

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

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

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

为了让客户获得最大利益，构建这个故事的最佳方式是什么？

解决方法

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

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

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

4. 是的，你说得对。一个需要多天才能完成的积压项目在完成之前不会被烧毁。那是故意的。这是因为在很长一段时间内“几乎完成”的工作在进行中的时间很长。通过将完成视为一个二元状态，它可以激励在开始其他项目之前完成项目。

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