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

Question

使用"天"作为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的块. .

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

速度与估计

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

这个速度会在前2-3次冲刺中发生变化并保持稳定,因此始终注意这个值

Answer 2

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

选择一个尺度，可以是小、中、大，可以是斐波那契数列，可以是 1 到 5，无论选择一个并使用它进行几次冲刺，这都会给你你的速度。如果您开始将比例从一种更改为另一种，那么比例之间的速度将不具有可比性（即不要这样做）。这些估计应该涉及您所有的 Scrum 团队。

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

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