敏捷认为小团队的人数规模应该是在魔法数字7上加减2。敏捷也推荐完整团队概念，就是说团队内部要有足够的技能以完成工作。因此，开发团队除了具备核心的开发技能，还要具有测试技能、数据库技能、用户界面技能。然而，很多组织仍然纠结于最佳的团队规模和有效的团队构成。
Scott-Ambler建议：根据项目需要，可以有敏捷小团队和敏捷大团队。小团队有标准的Scrum角色，比如scrum-master、开发团队和产品负责人。小团队还可以使用支持队伍，包括DBA、领域专家和测试人员这样的技术专家。大型团队需要“团队的团队（team of teams）”这样的方式。Scott认为：
典型策略是：把多个相关小团队组织起来，形成更大规模的团队，最有效的方式是围绕着系统架构的方式组织。每个子团队应该负 责一个或几个子系统，让他们可以像小敏捷团队那样，负责按时交付可工作的软件。这个策略常被称为“Conway法则”，因为是Melvin Conway在二十世纪六十年代后期提出来的，也是精益开发管理策略之一。
Steve Miller认为：除了Scrum推荐的角色之外，要想让团队做好质量保证和文档相关工作并不现实。他们改进了团队构成，增加了两个角色。软件质量工程师负责一个sprint的产出的质量，文档专家负责创建用户指南、管理员指南和培训材料。
同样地，Michael F. Dwyer在回应Scrum Development讨论组中一个有关团队大小的讨论时指出：
趁着Ron Jeffries还没说，我先借用他那个著名的话“2+2=5，因为这两个粗略的‘2’要比数字2更大一点。”团队规模可以是1个人这么小，也可以是500人这么大，完全基于你对团队的定义和成员的投入程度。
因此有一个共识：团队的规模和构成要根据各个项目具体情况调整。然而，我们应该如何评价我们的团队结构是否最高效呢？
Mike Cohn建议回答下列9个问题，而且都能得到肯定回答，那就是一个结构优秀的团队。问题列表包括：
- 团队的结构是否强调自身的长处，支撑短处，而且支持、激励团队成员？团队某个成员的弱点应该可以被其他成员的优势所补足。
- 团队结构是否将必须同时属于两个团队的人员数目降到最低（而且避免有人同时属于三个团队）？试图同时着手多个并行项目、或是多个任务，都会损害进度。
- 团队结构是否能将团队保持在一起的时间延至最长？应该更倾向于让成员能够在长期内保持在一起的团队设计，这能让团队的感觉和联系保持长久。
- 组件团队的结构是不是只在有限而且易于处理的情况下使用？团队应该是功能团队，围绕着端到端交付可工作功能的方式构建。
- 是不是两个pizza这样的食物数量足够多数团队食用？大多数设计良好的团队应该有7±2个人。
- 团队结构能够将团队之间的沟通路径数目最小化？如果在待开发应用中做一个小更改，就会带来大量团队之间的沟通，那么就得好好看看团队结构了。
- 现有结构是否鼓励团队沟通？如果换个结构，团队就不愿意这么做？高效的团队设计鼓励团队或个人之间的沟通，可能他们本来不想这么做。
- 团队设计是否支持对于责任的明确理解？结构应该推进共享所有权和共同成功的理念。
- 团队成员是否可以对团队设计提出建议？他们应该感到这是他们构建起来的团队。
在回答完上述问题后，您是否相信您有高效的团队架构？为了让敏捷的做法帮您实现高效团队架构，您过去采取了哪些必要措施？
