Scrum中的故事估计

我们开始了一个将使用Scrum/XP进行管理的项目。为了评估目的，我们预先编写了整个产品待办事项。我们要确保所有的故事都是以客户为中心，我们正在通过Scrum中的故事估计

故事的商业价值评估其中：莫斯科技术 - 必须，应该，可能，会/不会有这个实施
故事付出/复杂（=故事分）：1，2，3，5，8，13，21，100 - 与故事复杂性/努力，而不是理想的天持续时间

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

计算结果故事重要性基于价值&不重叠MoSCoW故事的努力。

但是，如果没有100个故事，我们迄今为止的故事（也被细分）的复杂程度在2到8之间，我们认为这是一个合适的故事大小，可以避免微观管理。但是有些故事彼此相关或相互依赖。我们有一些故事，如果先完成，可能需要更多的故事，而如果其他故事在他们面前完成，那么这些故事就会减少。

问题
是否有可能在开发过程中稍后调整故事点，我们可以用故事的任务，我们可以重新评估它们，新增，删除现有的还是这不是故事的情况下怎么办？因为改变它们的复杂性，也会根据计划速度改变结束日期估计。这种情况下的最佳做法是什么？

来源

2009-08-06 Robert Koritnik

有相关的估计和规划信息的博客文章：Sprint计划 - 只是在时间刚好够（HTTP：//www.agile42。COM/CMS /博客/ 2009/07/6 /冲刺规划，刚刚够，刚刚在时间/）。 – Doro 2009-08-08 04:53:10

@VadimKotov这将属于项目管理甚至软件工程，但由于它太旧了，我会把它打开。 – Korcholis 2017-10-19 13:29:53

@Korcholis我们正在努力解决旧的题外话题。它可以锁定历史，但（在关闭状态）。这是为了防止新的答案和新的类似的题外话题 – 2017-10-19 13:31:41

你绝对可以再次评估你的故事，你应该。只有当团队在Sprint计划会议即将开始之前向他们承诺时，才会锁定这些分数。

我使用过的一种做法是，在进行单个Sprint计划时，您应该再次评估每个故事。团队随着时间的推移学习，并通过估计和确定依赖关系来变得更加准确。请记住，Sprint发布的内容取决于团队，产品负责人定义整体积压。如果项目有时间限制，不要试图使估计值符合结束日期，如果你这样做，你是在自己设定失败。

请记住，使用Velocity你首先猜测你能完成什么。通常情况下，直到第三次或第四次冲刺时，才能确定球队可以管理的现实速度。是的，这确实意味着你可能认为团队可以为每个Sprint提供20分，实际上只能得到15分。是的，这意味着交货时间消失或者故事低于切割线。

至于依赖故事，你应该与你的产品所有者合作。如果团队与他们交谈，你通常可以重新排列故事。大多数人都会接受告诉他们的人：“如果我们现在做A就会采用完整的Sprint，但如果我们稍后再做，它将占用Sprint的15％”，这使得它很有说服力。

一个有用的练习是在Sprint中安排故事。在规划会议期间，所有故事都经过验证和讨论后，团队将制定日历并讨论他们何时想完成任务。通过在日历上放置目标日期，有助于识别故事之间的重叠和依赖关系。这可以识别本质上串行的事情，并可能导致Sprint失败。

希望这些信息对您有所帮助。

来源

2009-08-06 10:23:13 CertifiedCrazy

我的估计不是基于持续时间，而是基于复杂性，所以我想我会改变分数，以防我们真的错过了故事的复杂性。我认为这应该是相当罕见的。但感谢您的意见。 – 2009-08-06 12:37:24

估计不应该基于持续时间，他们应该基于复杂性。也许我误解了这个问题。但简单地说，直到故事正在作为Sprint的一部分进行工作时，只要产品所有者对它有好处，就可以重新布置/重新排列。这是关于敏捷的好事，可以改变积压的任何东西，直到它当前的Sprint的一部分。 – CertifiedCrazy 2009-08-06 22:50:12

我只能描述我的期盼。

当我们计划第一次冲刺时，我们决定完成18分。所以我们拿了几个故事，总估计是15分。正如我上面提到的，我们正在开始scrum的第一步，这就是为什么我们决定3个未使用的点和0.6的形式保证我们的成功。

但是我们对每个故事的估计只是近似的。我们也有一些独立的故事。而且我们没有制定每个故事的实施计划，因为我们认为它对敏捷方法学不太现实。

因此，我们的第一次冲刺只有8个完成点失败。

在我们进行第二次冲刺之前，我决定从旧的简单级联和迭代方法中挑选一些东西（我是一个scrum-master）。所以，在我们下一个春天计划做出正确的估计时，我们计划了每个故事（每个故事大约20分钟），包括简单的图表，所有的依赖关系，实施细节等等。计划很困难，需要2次会议。

但是第二次冲刺要好得多，我们几乎完成了所有事情（实际上我们已经完成了所有事情，但有一些错误）。我认为在第三次冲刺中我们会减少外形，并且会取得成功。

来源

2009-08-06 08:33:23 Roman

所以你真的改变了故事点吗？你的故事点与复杂性或持续时间有关吗？根据您的实际速度，您的结束日期也发生了很大变化。 – 2009-08-06 08:52:50

不，我没有。实施过程中出现的新问题我们将其解释为具有高优先级的新故事（如错误）。但是，非常好的计划在Scrum中非常重要。 – Roman 2009-08-06 09:18:30

从你的解释你已经做得很好。当然，总会有一些依赖的故事。有些甚至可能没有直接可见的客户价值;即建立架构和一些框架的初始努力）。但是如果你将它们排除在外，就会造成很多技术债务。如果可以的话，我建议你尽量让方程完整并以某种方式显示任务之间的关系。

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

通过这种方式，产品所有者会感到忽略依赖关系的痛苦，但仍然可以选择首先做最有价值的故事。如果产品负责人确信所有的故事都会在下一次冲刺中出现，那么您可以引导它们以最有效的顺序实施。例如，通过阻止未满足依存关系的项目（即，在故事“webenabled版本”完成后，您只能拥有“更改我的网站徽标”功能）。

祝您好运！

来源

2009-08-06 09:45:50 Adriaan

我们称这些故事为“科技故事”。我们没有计划，因为我们已经完成了大部分基本面。杰出的将在以客户为中心的项目中完成。 – 2009-08-06 12:44:51

关于双重估计有点棘手，即。由于我们首先研究的是具有最大价值和最小努力的故事，因此Story2可能会出现在Story1之前。但在这种情况下，你会使用更高的复杂性，你将不得不重新排序......我想这种情况下的自动化是没有问题的。但是你的双重估计的建议是可以的。我们只是在评论中添加它，并在冲刺计划时使用它。 – 2009-08-06 12:47:52

有一些模式可以帮助您以用户故事的分割方式保留投资，这意味着您将尽量节省依赖性，大小，可测试性和价值。您可以在这里阅读更多关于：http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/理查正在积极地申请和改进它们，他并不孤单;-)

只要知道分裂和保持依赖关系（就像在甘特图中创建关键路径一样）将胜过团队创造力的能力，并就这些故事进行谈判，并可能隐藏一个“无价值的主张”。

HTH
ANdreaT

来源

2011-01-20 10:28:30 ANdreaT

Scrum中的故事估计

回答

相关问题