如何更改故事点以便在Scrum中使用估计

Question

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

那么，如何让团队变成故事点？什么能激励团队成员这样做，我们应该如何应用转换？

Answer 1

如果你想改变为使用故事点而不是持续时间，你只需要开始估计故事点。 （我在这里假设你有权为你的球队做出这样的决定。）

选择一个比例尺，可以是小的，中等的，大的可以是斐波那契数列，可以是1到5，无论选择哪一个并使用它为几次冲刺，这会给你你的速度。如果你开始改变从一个到另一个的尺度，那么尺度之间的速度就不会是可比的（即不这样做）。这些估计值应该包括你所有的Scrum团队。

说了这么多，你仍然需要知道这会花费你多少钱。没有许多会计师会接受答案：“我会告诉你6个月内会花多少钱”。所以你还需要估计项目的持续时间，这会给你带来成本。这个估算可能会由团队中的高级人员完成

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

Answer 2

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

Answer 3

问题是故事点定义了努力。

天是持续时间。

这两者有一个几乎随机的关系。 。该功能基于实际工作人员的技能。

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

他们不知道这个抽象'努力'的事情。他们不知道平均技能的假设人需要多长时间才能完成这项工作。

你可以做的最好的是两个故事点（努力）和天（持续时间）。

你不能用另一个替换一个。如果您尝试仅使用努力，那么您最终需要花费数天才能进行规划。你必须将一个人应用到故事点，并通过努力来计算持续时间。

Answer 4

当我转向积分时，只有当我能够满足以下两点时才决定使用积分： 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.

这就是为了积分和原始积压。如果你有一个新的故事，将它与该列表进行比较，看看它适合哪里（更大/更小的过程），并给它的邻居的价值。

速度&估计

估计将需要多长时间，你要经过积压，做了第一个冲刺计划。使团队挑选的故事和VOILA！的总点数相同，这是您的第一个速度测量。然后，您可以将积压点中的积分总和除以该速度，以知道需要多少冲刺。

那速度将有所改变，在第2-3冲刺定居所以它总是好的，盯紧该值