团队估算游戏作为一项敏捷估算技术，有时也被称为斐波那契博弈，是通过story points或粗略的数量级来确定相对规模。策划扑克与之类似，使用卡片来描绘story points。

在进行团队估算时，敏捷团队围绕user story，借助卡片或便签进行三轮协作式的规模磋商，并把各自估算的结果贴到白板上。每一轮，团队成员都可以调整user story的规模估算数值，并讨论story的次序。在听取了所有敏捷团队成员的意见后，一旦确定了相对规模，就要对白板上的结果进行整理，直到三轮下来，给出user story的规模。

队估算游戏使用斐波那契数列作为相对规模大小的估算基础，反应了大型项目中，不同需求固有的复杂性和不确定性。

斐波那契数列（Fibonacci Sequence），又称黄金分割数列、因数学家列昂纳多·斐波那契（Leonardoda Fibonacci）以兔子繁殖为例子而引入，故又称为“兔子数列”，指的是这样一个数列：1、1、2、3、5、8、13、21、34、……在数学上，斐波那契数列以如下被以递推的方法定义：

F(1)=1，F(2)=1

F(n)=F(n-1)+F(n-2)（n>=3，n∈N*）

《敏捷估计与规划》一书的作者Mike·Cohn在实践敏捷估算时认为，斐波那契数列近似呈指数增加，相对于1、2、4、8、16……数列，看起来不那么精确，可以避免给人一种确定性。因此，他更偏向于使用斐波那契数列，并将其改良为1、2、3、5、8、13、20、40和100。

CMMI改善敏捷估算

在许多项目中，好的估算是一个难以企及的人工产物。敏捷技术试图通过估算游戏来确定backlog的相对规模大小，从而解决估算问题。故意将backlog的相对规模与工作量切割，可以迫使团队换种方式思考。“大致的正确”与“确切的错误”是团队估算游戏的最终目标，CMMI中，项目规划过程领域可以为敏捷估算带来更多的清晰度和稳健性。

例如：

-  强调用户/客户需要，这样做可以尽早了解项目的完整范围。无论是epic还是user story，都需要足够的细节来估算相对规模。完整性是目标。

-  在估算中，考虑所有类型的工作产品，并为之设置期望值。软件本身，只是一种工作产品。初次之外，还有其他工作产品，例如user story、DoD等。

-  确保工作量估算是策划的最终结果。工作量使得敏捷团队可以度量其速度，并用来改善后面的估算。

更多例子与建议，可在项目策划过程域的信息组件中获取

在团队估算游戏中，Scrum团队与Scrum Master和PO一起，估算每一个epic和user story的规模，是产品backlog开发或sprint策划的一部分。团队估算游戏的实质，是具备技能多样性的团队，针对每一个user story的功能性，进行深入的讨论。清晰的epic和user story缩短了PO澄清产品backlog的时间，改善了团队在一个sprint中“get it right the first time”（一次性搞定）的能力。既然清晰的epic和user story如此重要，那么CMMI又能帮上什么忙呢？在需求管理过程域的特定实践1.1为我们提供了参考，比如：

-  应明确识别需求来源，尽量减少混淆与可能的范围蠕变。

-  定义什么是良好的需求，并将其记录下来，以便团队成员可以理解与使用。

-  在需求的创建和评审过程中，沟通渠道应是透明而开放的。

项目策划

需求管理