如何更改为在Scrum中使用Story Points进行估算

Question

使用“days”作为Scrum中任务估算的单位我发现很难改变使用Story Points。我认为应该使用故事点，因为它们彼此之间更具可比性 - 更少依赖任何人处理任务的资格等。但是，当团队习惯时，让团队开始使用故事点并不容易以天计算。

那么，如何让团队更改为Story Points？什么应该激励团队成员这样做，以及我们应该如何应用这个开关？

Answer 1

当我切换到积分时，我决定只能满足以下两点; 1）查找和参数，证明交换机是合理的，这将说服团队 2）找到一种简单的方法来使用它。

<强>说服

我花了很多关于这个主题的阅读，但终于找到了说服我和我的团队的论点：几乎不可能找到两个程序员同意任务将采取的时间，但同样的两个程序员几乎总是同意在显示两个不同的任务时哪个任务最大。

这是您“估算”待办事项所需的唯一技能。在这里，我使用“估计”这个词，但在这个早期阶段，它更像是将待办事项从强硬到轻松订购。

将积分放入待办事项

这一步是在整个Scrum团队的参与下完成的。

开始在新的电子表格中逐个删除故事，同时保持以下顺序：顶部的最大故事和底部的最小故事。这样做直到所有故事都在列表中。

现在是时候为这些故事加分了。我个人使用扑克规划量表（1 / 2,1,2,3,5,8,13,20,40,100），所以我将在本例中使用。在该列表的底部，您可能会有微任务（需要4小时或更短时间才能完成）。给每个微任务赋值1/2。然后通过将值1（比例尺中的下一个）赋予故事继续向上列表，直到明确故事要大得多（2而不是1，因此大两倍）。现在使用值'2'，继续列表，直到找到一个明显有3而不是2的故事。继续这个过程一直到列表的顶部。

注意：尽量保持绝大多数积分在1到13之间。第一次你可能有一堆大故事（20,40和100）并且你必须将它们制成小块或小于13的块。

这就是积分和原始积压。如果您有一个新故事，请将其与该列表进行比较，以查看它适合的位置（更大/更小的过程）并为其提供其邻居的值。

速度＆amp;估计

要估计完成积压工作需要多长时间，请执行第一个sprint计划。制作团队选择的故事和VOILA！的总分，这是你的第一个速度测量。然后，您可以将积压中的积分除以该速度，以了解将需要多少冲刺。

速度会在前2-3次冲刺中发生变化并保持稳定，因此始终关注该值

Answer 2

如果您想要更改为使用故事点而不是持续时间，您只需要开始估算故事点。 （我假设你有权为你的团队做出决定。）

选择一个刻度，可以是小型，中型，大型可以是斐波纳契序列，可以是1到5，无论选择哪一个并将其用于几个冲刺，这将为您提供速度。如果你开始将比例从一个改为另一个，那么比例之间的速度将不具有可比性（即不要这样做）。这些估算应该包含所有Scrum团队。

话虽如此，你仍然需要知道这会花多少钱。没有很多会计师会接受这样的答案：“我会告诉你在6个月内会花多少钱”。所以你仍然需要估计项目的持续时间，这将给你成本。这个估计可能会由团队中的高级人员完成

然后每个月你的速度会告诉你和会计师第一次成本估算的准确程度，你可以相应地进行调整。

Answer 3

首先让一天等于一点（或一些严格的比例）。这是一个很好的入门方式。经过几次冲刺后，你可以开始鼓励他们使用更多的相对点（即与此相比有多大）。

Answer 4

问题在于故事点定义了努力。

天数是持续时间。

两人的关系几乎是随机的。 duration = f ( effort )。该功能基于实际工作的人的技能。

一个人知道他们需要多长时间来完成这项工作。这是持续时间。在几天内。

他们不知道这种抽象的'努力'的事情。他们不知道普通技能的假设人需要多长时间才能做到这一点。

你能做的最好的是 - 故事点（努力）和天（持续时间）。

你不能用另一个替换一个。如果您尝试仅使用努力，那么您最终需要花几天时间进行规划。您必须将一个人应用于故事点并计算工作的持续时间。