Scrum中的故事估计

Question

我们开始了一个用Scrum/XP管理的项目。为了评估目的，我们提前编写了整个产品的待办事项清单。我们正在确保所有的故事都是以客户为中心的，我们是通过

• story business value：MoSCoW技术--必须、应该、可以/不会拥有这个implemented
• story工作/复杂性 (=故事点)：1、2、3、5、8、13、21、100 --与故事复杂性/努力相关，而不是理想的持续时间

。

100个故事点可能有一些会/不会有的故事，因为它们实际上是更大的复杂故事，如果需要的话，这些故事稍后会被分解。

计算故事重要性是基于价值和努力，而不是重叠的MoSCoW故事。

但是如果没有100点的故事，到目前为止，我们的故事(也被分解)的复杂性在2到8之间，我们认为这是避免微观管理的一个合适的故事大小。但有些故事变得相互关联或相互依赖。我们的故事可能需要更多的如果先做，少一些其他的故事会在他们之前完成。

问题

是否有可能在开发过程中调整故事点，就像我们可以对故事任务进行重新评估、添加新的、删除现有的或者不是故事的情况？因为改变它们的复杂性，也会改变基于计划速度的结束日期估计。这个案子的最佳做法是什么？

Answer 1

你绝对可以重新估计你的故事，你应该这样做。只有当团队在Sprint计划开始之前的Sprint计划会话中向它们提交时，才会锁定这些点。

我使用过的一种实践是，在执行“个人短跑计划”时，您应该再次评估每个故事。随着时间的推移，团队将学习，并将变得更加准确的估计和识别依赖。记住，Sprint中的内容取决于团队，产品所有者定义了总体的待办事项。如果项目是有时间限制的，不要试图使评估符合结束日期，如果你这样做了，你是在为自己设置失败。

请记住，使用“速度”，您可以从猜测您能完成的任务开始。通常情况下，直到第三或第四冲刺，你才能确定一个真实的速度，团队可以管理。是的，这确实意味着，你可能已经假设球队可以提供20分每短跑，实际上只能做15分。是的，这意味着送货的时间会提前，或者故事会下降到截止线以下。

至于依赖的故事，你应该和你的产品所有者一起工作。如果团队与他们交谈，你通常可以重新安排故事。大多数人都能接受这样的人：“如果我们现在做A，它将需要完整的Sprint，但是如果我们稍后做A，它将花费15%的Sprint”，这使得它非常有说服力。

尝试的一个有用的做法是在Sprint中安排故事。在计划过程中，一旦所有的故事都得到验证和讨论，团队就会拿出一个日历，并讨论他们想要完成的事情。通过将目标日期放置在日历上，它有助于识别故事之间的重叠和依赖关系。这可以识别本质上是串行的东西，并可能导致Sprint失败。

希望这些信息有帮助。

Answer 2

根据你的解释你已经做得很好了。当然，总是会有有依赖性的故事。有些甚至可能没有直接可见的客户价值；即最初建立架构和一些框架的努力)。但如果你把它们排除在外，你就会产生大量的技术债务。如果可以的话，我建议你试着使方程完整，并以某种方式显示任务之间的关系。

例如：-任务3是在任务2之后完成的8点，如果独立完成则是12点。

这样，产品所有者将感受到忽视依赖的痛苦，但仍然可以选择先做最有价值的故事。如果产品负责人确信所有的故事都是在下一个sprint中完成的，那么您可以引导它们以最有效的顺序实现。例如，通过阻塞没有满足依赖关系的项(即，您只能在故事'webenabled版本‘完成后才有“在网站上更改我的徽标”功能)。

祝好运!

Answer 3

我只能描述我的罪责。

当我们计划第一次冲刺时，我们决定我们可以完成18分。因此，我们采取了几个故事，总估计是15点。正如我前面提到的，我们在scrum中迈出了第一步，这就是为什么我们决定使用3个未使用的点数和0.6的形式因素来保证我们的成功。

但我们对每一个故事的估计只是近似的。我们也有一些依赖的故事。而且我们没有制定每个故事的实现计划，因为我们认为它与敏捷方法论是不可忽视的。

结果，我们的第一次冲刺失败了，只有8分。

在我们的第二次冲刺之前，我决定我们应该从旧的、好的、简单的级联和迭代方法中吸取一些东西(我是一个scrum高手)。因此，在我们的下一个春季计划做出正确的估计时，我们计划了每个故事(每个故事大约20分钟)，包括简单的图表、所有依赖项、实现细节等等。规划工作很困难，花了两次会议。

但是第二次冲刺要好得多，我们已经完成了几乎所有的工作(实际上，除了一些bug之外，我们已经完成了所有的工作)。我认为我们会在第三冲刺中采取更少的形式因素，这样会成功的。