Scrum - 您何时估算产品待办事项的工作量？

您的团队在Scrum流程的哪一部分对完成给定产品积压项目所需的工作量进行了有根据的估算？

例如,假设您有一个产品积压项目,其中显示"用户将能够提供他们的电子邮件地址并收到一封电子邮件,其中包含重置密码的链接",计划用于Sprint 1.

您是否以非常粗略的估计开始冲刺并进行优化？这个"用户故事"什么时候变成了程序员可以及时估计的粒状动作项？(例如:"使用一个文本框和提交按钮构建Web表单"= 2小时)

在冲刺开始之前,您是否进行了更精细,更准确的估算？冲刺开始时？或者在sprint期间,只要设计师/程序员最终碰到任务？

通常,估算应在每个sprint开始时以2个级别完成:故事级别和任务级别.为了获得最佳结果,产品所有者和团队应该每次都一起做,尽管有时在没有产品所有者在场的情况下,团队在任务级别进行估算是可以接受的.

项目估算/路线图建设(故事层面)

在您的第一个sprint中,您必须估计至少80%的积压项目(我假设产品负责人已经优先考虑)来构建合理的项目路线图,其中包括以短跑和初始估计投影分组的故事项目长度.

此时,每个故事的估计是使用而不是小时,天或周来完成的,而是相对于大小的单位(包括努力,复杂性和风险),例如故事点.我们在此阶段使用Fibonnaci量表和规划扑克.整个团队积极参与这一过程非常重要.

在那之后,团队必须猜测他们能够在第一个冲刺中完成多少个故事,这将是他们的初始估计速度(点/迭代).通常,最好不要使用1个月的冲刺,而是使用2周或1周的冲刺长度来提高估计准确性.第一次计划通常需要一整天甚至两天,具体取决于积压大小,团队规模和短跑的长度.

在第一轮故事估计之后,产品所有者和团队可能希望重新确定积压的优先级以优化成本/效益比,因此可能会有一些来回,直到达成协议.

你应该得到这样的东西:

PROJECT ACME ROADMAP

SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)

SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)

SPRINT 3 (39 points)
--------
...

在下面的冲刺中,这个路线图将在每个冲刺开始时反复修改,将速度调整到团队获得的实际速度,并根据需要重新计算项目长度.有时,随着团队的发展和需求的变化,重新评估故事也是必要的.但是,修改路线图的时间不应超过半天.

使用燃尽图表,利益相关者可以看到此级别的进度,其中X轴是冲刺,Y轴是故事点.

冲刺估计(任务级别)

每个sprint的规划阶段的第二部分用于将每个故事分解为任务.在这里,任务应该是高度技术性的,并且使用小时来估算.我们的政策是,如果任务估计超过8小时,那么无论如何都需要将其分解为更详细的任务.结果将是sprint backlog,其中任务按故事分组,sprint burndown图表,其中X/Y轴应分别为sprint和hours的天数.

它应该如下所示:

Sprint 8
--------
Story 17
  Task 1: 8 hours
  Task 2: 6 hours
  Task 3: 2 hours

Story 18
  Task 1: 8 hours
  Task 2: 6 hours

Story 19
  Task 1: 6 hours
  Task 2: 3 hours
...

所以基本上,这些是你应该在每个sprint开始时做的两种类型的估计,通常第一个sprint需要更多的努力来构建初始项目路线图.

粗略估计应该在sprint计划之前完成,其中该团队应该选择该特定项目.通常我们会在上下文切换期间检查产品待办事项或在sprint期间停机,以便对"故事点"中的新项目进行粗略估计,因此产品所有者可以在下一个sprint计划之前正确地对它们进行优先级排序.

我们的冲刺计划通常在新冲刺开始时计时为2小时.这是当我们与产品所有者会面并从积压中挑选物品时,其中大部分都是粗略估计并正确划分优先顺序.缺少估计是在现场完成,然后我们做这个时间窗口内的故事(这通常是相当紧张的工作)的"细粒"任务撬动事实,该公司的其余部分是意识到这一点,POS和利益相关者可以找出下落不明的详细信息.

当然,有时执行任务序列将与计划任务不同,然后必须进行调整,并且可能需要重新调整燃尽图.

任务中的Burndown
我们只是使用我们的燃尽测量的任务数量.通常你会做一些像实际时间或理想时间的事情,但这对我们来说已经足够好了,而且显然很有趣,需要一些澄清.

我们不估计这些任务的时间,所有重要的是故事的故事点估计(粗略估计),我们把它放在理想的人日.

如何将故事分成任务更多的是团队分配和一般进度指标,而不是为我们做出准确的小时估算.

最后,我们已经处理了x个故事点,并从与sprint团队中实际可用人日相关的因素中获得了我们的焦点因素.

最后,故事点的粗略估计是我们的故事选择的基础(即,我们可以在冲刺中做多少sp).我们往往得到的粗略估计更好 - 我认为这很重要,因为产品负责人在优先积压的项目大多是在此基础上,从不基于任务的估计无论如何 - 因为这是团队内部.

由于任务没有明确的时间估计自己,重点是故事点的粗略估计.如果任务一起花费的时间超过估计的故事点*焦点因子,我们只是粗略估计错误或者应该在sprint计划期间纠正它,此时大多数信息应该可用或整理出来.