Skip to main content

敏捷实践中使用故事点常犯的12个错误

· 13 分钟阅读

原文作者：Maarten Dalmijn

原文地址：https://medium.com/serious-scrum/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7

译者：付新圆&柴晓燕

几乎每个Scrum团队都在使用故事点，但故事点不是官方Scrum指南的一部分，就存在很多不同的解释和使用方法。本文旨在消除围绕故事点的神秘感，也将分享我在敏捷实践中遇到的对故事点的误解。

故事点代表什么？

故事点是用于估计敏捷开发中用户故事的相对大小和复杂性的度量单位，表示投入PBI (Product Backlog Item产品待办事项) 所需的工作。每个故事点代表一个时间的正态分布。例如：1个故事点可以表示4-12小时的范围，2个故事点可以表示10-20小时的范围，依此类推。这个时间分布在预估过程中是未知的。通过参考PBI (Product Backlog Item产品待办事项) 得到相对估计值，虽然不知道完成任务的具体时间，但可以粗略地知道需要多长时间完成任务。

使用故事点有什么好处？

故事点使团队能够：

  • 快速预估问题。预估可以参考已经完成的产品待办事项。这比没有任何参考的预估要快。
  • 估算时无需给出具体的时间承诺。以小时为单位进行估算时，您需要做出精确的时间承诺。但估算故事点时，不需要做出确切的承诺，不需要对特定问题指定多少小时完成。
  • 拥抱预估带来的不确定性。故事点指定了未知的时间范围，从故事点的特定Fibonacci-like序列中进行选择可以捕获不确定性。
  • 足够准确，可以提前计划冲刺。可以更好地管理利益相关者对未来工作的时间期望。

使用故事点时常见的12个误区

1.讲故事只是指复杂性，不确定性或价值。​

PBI (Product Backlog Item产品待办事项)的实现需要复杂的算法。有些PBI (Product Backlog Item产品待办事项)很复杂，但并不需要很多时间，团队之前已经做过了此类的操作，所以他们能快速完成。相反的情况也会存在，比如一个简单的PBI需要很多时间，团队需要重构一小段代码，但影响了很多功能，结果许多功能需要进行回归测试，这将花费大量时间。

预估的不确定性在故事点fibonacci-like序列本身中捕获：1、2、3、5、8、13、20、40、100。从该序列中选择特定数字反映了不确定性。当不确定性太大而无法估计时，则可以使用“?” 卡。

故事点提供了一个粗略的估计，并不能说明PBI的价值。该项目可能非常有价值，或者根本没有增加任何价值。故事点可以帮助项目确定PBI的ROI（投资回报率），您可以考虑将功能与价值一起交付。

故事点与工作相关。 复杂性，不确定性和风险是影响工作量的因素，但它们单独使用时不足以决定工作量。

2.将故事点转换为小时。​

通过将故事点数转换为小时数，您就无法从相对估计的速度中受益。您开始以小时为单位工作，冒着做出承诺的风险。当您将故事点的时间范围从10-20个小时减少到15个小时时，它提供了一种错误的准确性。当您开始在确切的时间范围内工作时，团队在预估上达成一致就会非常困难。

3.平均故事点数。​

在计划扑克游戏的过程中，团队的一半人预估PBI为3个故事点，另一半人预估为5个故事点。只需将4个故事点作为估算值​​，就可以解决讨论。这样并不是100%准确的，关键是要足够准确，提前做好计划。团队不应这样做，因为它提供了错误的准确性。另外，您可能会因为平均而失去一次有价值的讨论。也许5个故事点是一个更好的估计。

4.在冲刺期间调整故事点对问题的估计。​

当团队开始处理问题时，即使事实证明他们的预估是不准确的，团队也不应调整“故事点”。如果预估不正确，则它是最终冲刺速度的一部分。有时预估不正确是正常的。您不会丢失这些信息，这将成为团队历史速度的一部分。

5.从不讲故事的bug。​

一个与当前冲刺无关的bug应该只在故事中提到，该bug是团队需要完成的工作。如果团队在冲刺期间保留了固定的时间来处理bug，那么这就不适用。与冲刺中的问题相关的bug不应该用故事描述，因为这是原始评估的一部分。

6.将故事点增加到小型任务中。​

调查一些关键的事情应该有时间限制，这件些关键的事情通过经验可能只需要4个小时来完成，就无需在其中添加任何故事点了。

7.调整参考PBI的冲刺。​

当一个团队调整参考PBI的冲刺时，那么不同冲刺的速度不再具有可比性。团队会丢失信息，您将无法再使用历史速度来提前计划。最好使用一系列最新的PBI作为参考。

8.故事再次指出未完成的问题。​

将未完成的PBI移至下一个冲刺时，无需重新估计。这个估算可能不准确，但这不成问题。作为冲刺计划的结果，团队将了解完成问题所需的所有任务。这些任务的估算以小时为单位。因此，下一次冲刺，团队将知道完成PBI仍需要多少时间。PBI未完成的将成为速度的一部分。

9.因为有特定的开发人员来处理，而调整故事点估算值。​

故事对应的PBI与参考的用户故事相关，由团队完成。团队成员讲述了PBI的故事，并在规划会议中就估算值达成了共识。对于高级开发人员，PBI可能是3个故事点，对于初级开发人员，一个PBI可能是8个故事点。团队工作量应达成协议，并将其用于计划。您不应调整故事点，因为每个PBI都将由特定的人来完成。也许当他们开始处理该问题时，高级开发人员正在处理生产问题。然后，初级开发人员就需要将其剩余的工作捡起来。

10.切勿调整参考PBI。​

当团队组成发生变化时，这可能会影响速度和故事点评估。他们俩都依赖于执行工作的团队。想象一下，当两个高级开发人员在场时，您就可以从故事中找到问题所在。当您要开始解决这些问题时，他们俩都离开了公司。现在，团队中有两个新的初级开发人员。建立一个新的用户故事参考是很好的实践，它需要整个团队来进行。这样可以确保每个人在讲故事时都在一个步调上，并给团队一些时间来建立新的速度。随着团队的越来越成熟，估算能力也越来越强，建立新的参考PBI可能是一个好主意。

11.与专家保持一致。​

在制定冲刺计划时，团队可能会与专家保持一致。解决此问题的一种方法是让专家详细说明这项工作，然后让团队的其他成员在没有专家的情况下进行评估。积累特定的专业知识是不可避免的，但不要让这削弱了团队的估算能力。

12.在回顾会中不讨论错误故事指向的问题。​

每隔一段时间，团队都会指出故事评估的错误问题，讨论这些问题并尝试了解这些问题非常重要的，这样未来的评估就会更准确。在我的一个团队中，我们忘记了在评估时考虑测试数据的创建，因此，我们特别讨论了创建测试数据是否适用的每个问题。如果适用，我们会询问他们是否考虑了测试数据的创建。这大大改善了我们的评估质量。

结论

故事点的概念很简单，但很难应用，几乎每个Scrum团队都使用它们，但它不是官方的Scrum指南的一部分。正因为如此，人们对如何使用故事点有不同的看法。术语“故事点”本身已经令人困惑，因为您也可以将它用于用户故事以外的工作类型，在这个“点”字上，说明一个故事点代表了价值。正如一位同事指出的那样，或许用“计划因素”一词来说故事点会更容易让人理解。本文旨在帮助大家了解在使用故事点时可能会犯的错误，并以正确的方式应用它们。