当组织实施规模化敏捷时，企业往往面临着管理多团队的挑战。而如果有多个团队在一个项目中工作，协作就变得更加复杂，尤其是在做估算时。
团队需要进行估算和计划，并根据计划跟踪进展，以便产品负责人对工作进行优先级调整，并与干系人沟通出最后交付产出物的时间。
但多团队工作带来了一些额外的挑战，包括：
- 当面临不同团队的技能与经验水平有差距时如何处理？
- 能否在不需要团队所有成员参加的情况下进行估算工作？
- 当不知道哪个团队将负责哪些工作时，提前做估算是否可能？
这里我有一个解决方案分享给大家，但在此之前，让我们看看两个在大部分组织面对多团队估算时会犯的主要错误（根据在我的敏捷导师社区中的讨论，这些错误如今依旧普遍存在）：
错误#1：建立的估算无法反映所有团队的能力
第一个错误往往发生在当企业精心挑选一组人员来对整个待办列表进行估算时。这本身是一个不错的主意（实际上我建议你稍晚一些做这件事）。这肯定比让一个庞大团队的每个人都对每项任务进行估算来得快和高效，而且你可能认为如果你能找到正确的人，就将得到很有见地的估算结果。
但这恰恰是事情容易出错的地方，因为如果你没有对将要完成的工作非常熟悉且能够充分代表跨职能团队能力的人选，那么你的估算的视角将会是片面（和不准确）的。
不幸的是，如今的企业中这一切正发生在：估算由游离于被估算的工作之外的人参与，又由实施工作的团队成员来完成。
这导致的后果之一是，得出的估算结果远比团队可能达成的目标更有野心（尤其是当这些结果被用于竞标固定价格合同时）。然而一个较低的估算虽然一开始也许让客户与干系人开心，但随着项目不可避免的延期，客户开始不安，信任被削弱，甚至可能导致合作关系瓦解。
更糟糕的是，鲜少有人将此归咎于估算。最后，团队挣扎着在不可能的截止日期前仓促交付的同时，面对着与日俱增的压力和批评。
错误#2：把故事点等同于时间
第二个错误发生在组织尝试通过要求所有团队使用故事点的统一标准来建立一致性及可预测性。一个流行（但不正确）的做法是强制所有团队使用一个固定的时长来等同于一个故事点，例如1个故事点为3小时，3个故事点为8小时。
同样的，我能理解这背后的逻辑：这看起来对于管理者是一个相当简单的能够一眼看出团队效率的方法。
但，这是无效的。
把故事点等同于小时数来定义，就把故事点最大的好处给埋没了，那就是被赋予某项工作的点数并不取决于由谁来完成它。就好比不论跑得快或跑得慢的人参加一英里的比赛，一英里始终是一英里。所以不该把故事点和时间划等号。
更糟糕的是，当所有团队的故事点都被定义为小时数，管理层会觉得团队间很容易仅仅通过速率来比较，而事实并非如此。
那么大型项目该怎么做？
所以针对多团队参与的项目，该如何建立有效的估算？
进行规模化估算，需要建立一个针对所有团队的公共基线，团队以此展开估算，并跟踪共同目标的达成进展。
但这需要用一个对所有团队都有代表性的方式来做，而不是简单的强制要求大家接受一个标准。
方法如下：
把正确的人召集到一起
建立跨团队统一基线最好的办法是从每个团队选取一位或多位代表，人数取决于参与项目的团队数量及规模。如果只有两三个团队，可以考虑让每位成员都参与进来，但对于更大数量的团队则可能每个团队2-3名代表更合适。
团队可以选择他们认为能够做出最佳估算的成员，通常是更资深的成员，但也不总是如此。团队还应该考虑将他们代表成员的技能进行重复叠加，例如，如果只有一部分工作是JavaScript开发，就不需要派三个优秀的JavaScript开发人员。
估算各种类型的待办事项
这些代表成员在一起使用估算扑克，理想情况是面对面，但考虑到有些代表可能是异地的，也可以采用虚拟的方式。他们不会把整个产品待办列表都估算了，那可能是个大工程，一般来说他们只会对其中的10-20项工作进行估算。
那意味着当这个会议结束时，每个人会带走一个由所有人达成一致的10-20个项目的估算列表。且每个团队都有至少一位成员参与了这些估算过程，可以将其中的细微差别及假设分享给团队。
然而重要的是，代表们需要对各种类型的 待办任务进行估算，这样当各团队以这个基线为基础进行相对估算时会容易一些。你不会想要对20个很相似的任务进行估算，因为当其他团队参考这个结果对完全不同的待办事项进行估算时，差别可能很大。
明白不需要把每个人和每件事都关联起来
我建议进行估算的大约10到20个产品待办事项，并不需要每位代表都能理解每一项。例如，一个核心科学计算模块也许代表了多团队的整体工作，但房间里的个别估算者却与这个任务没有关联。
那也没关系，并不是每位参与者都需要能够关联到每个事项。我们只要确保大部分被估算的事项能够被大部分团队所理解。
这意味着，选择这大约10到20项被估算的任务是这次会议参与者们的责任。他们能够更好的判断被选择的任务是否在这个产品中有
足够广泛的代表性，以及是否大部分估算者都能参与到对大部分任务的估算中。
使用由每个团队的成员代表所达成一致的估算来建立的基线，能够使所有团队采用统一的方法来进行估算工作。
关于作者
Mike Cohn 是帮助企业适应和改进敏捷过程及技术，以建立极致高效团队的专家。著有《用户故事与敏捷方法》，《敏捷估算与规划》，《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。Mike是敏捷联盟及Scrum联盟创始人之一，可以通过邮箱 hello@mountaingoatsoftware.com 与他取得联系。如果你想在敏捷方法取得成功，也可以请Mike每周给你一个小建议。
关于译者
Scrum中文网翻译组：Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
原文链接：
https://www.mountaingoatsoftware.com/blog/how-to-estimate-story-points-with-multiple-teams
