一种快速估算故事点的方法

估算故事点是一个令人乏味的过程。正是这样的乏味过程使得一些团队放弃了有助于预测速率的估算点。何不放手这种有效的方式来预测未来的工作，而找一种更快的估算过程？不仅是快，而且有趣！是的，估算和有趣可以同时进行！

我们曾面临过这种情况，我们必须知道是否可以在确定的发行日期之前推出新的网站，该网站涉及到全新的创意、基于服务的架构方法，并且与后端系统有交互影响。有几个敏捷团队（内部和外部）是该项目的部分团队，并且需要知道是否可以按期推出。我们必须决定是否可以在可用时间内及时地完成剩余的工作，或者必须缩小工作范围以满足推出日期的要求。我们把团队都聚到一块，也包括主要的经理们（一共有15个人），尽快地弄清楚是否可承诺完成。我们提前修整了超过125个用户故事，并且可以在15分钟左右的时间内估算完这些用户故事。最后的时候，我们确定需要缩减范围以便满足日期要求，并且由业务人员决定缩减哪些内容可以争取一些时间。

如果你有一个同地协作的团队，这有种方法可以快速地估算多达100个用户故事。当团队需要提供一个可靠的时间表、什么时候可以完成用户故事的开发和测试，由此可以计划主要的项目发布，这个过程方法则使用得很成功。并且它可以替代像计划扑克那样耗时的方法。

所以不要因为耗时就停止了估算，而要用不同的方式！这种新方法的风险是微不足道的，这也是敏捷，并且支持大胆前行并需要紧迫交付可工作软件的项目。

假设条件

• 要有待办列表修整会议并且团队成员理解大多数用户故事的要点
• 同地协作的团队
• 有一面墙或者会议室可以让团队使用
• 每个用户故事被独立打印，必须在估算过程之前准备，并且提前贴在墙上。

  

• 在墙上写下斐波那契数列：1-2-3-5-8-13-31并且加上一列“？”

  

过程

• 团队人员排成一排
• 要求第一名成员把一个用户故事放到他认为可以正确反应故事点值的那一列上
• 第一名成员做完后排团队成员的最后一个位置
• 下一个团队成员可以挪动已经摆好的用户故事，也可以选择另外的用户故事，把它挪到他认为可以正确反应故事点值的那一列
• 继续这个过程，直到所有用户故事都摆放完毕。

  

• 在此循环过程中，会有用户故事在不同的估值点列中来回挪动，引导师可以把这些用户故事挪到列表的上方，用于最后的时候讨论。
  • 当大多数的故事都摆放好后，让团队成员投票选择这个“问题”故事属于哪一列。
  • 如果无法达成一致，把这个故事放到最高值的一列。
• 也会有一些故事需要更多的信息，把他们放到“？”一列
  • 把“?”一列的故事降到最低
  • 如果这样的故事太多了，也许再需要一个列表修整会议，可以让团队成员很清晰地了解故事细节。
• 放置故事以及讨论协商的整个过程会很快
  • 团队在整个放置故事的过程中都感觉到很有趣
• 一旦团队成员对放置的故事都满意，计算每一列故事的个数，并且乘以故事点，从而得到所有的故事点。

  

• 这也有助于团队基于当前的速率估算剩余的迭代。
• 注意，可能会有一些高优先级的故事已经在迭代中——这个练习是专注于弄清楚列表中有多少剩余的工作。。

快试一试吧！如果你现在还没有修整列表，可以考虑把它作为一个例子，让团队看看怎么进行的。例如，如果你有一个名为“摊煎饼”的项目，可以创建例如这样的用户故事，“定义煎饼类型”、“创建购物清单，因此我不会忘记”、“去商店购买需要的所有材料”、“把材料组合起来，检查是否准备就绪”、“开始烹调”、“招待”等等。这些故事很容易理解。只要团队有足够的故事可以很好地演示整个过程就可以了。

关于作者

Mary Ann Michaels 具有多年的大规模零售系统实现的项目领导经验。她是敏捷的忠实粉丝，在工作中学会使用一些工具，以及从MBA和各种培训课程中了解敏捷方法论如何让团队快速地交付可工作的软件。它曾就职于多个大型公司，包括沃尔玛、Levi Strauss & Co、Williams Sonoma以及 Coldwater Creek。并且同时拥有技术与业务能力，管理应用开发并支持团队和配送中心。她拥有密歇根州立大学的数学/法语学士学位，以及佩珀代因大学的MBA学位。

查看英文原文：A Fast Story Point Estimation Process