使用特性团队（Feature Team）
敏捷团队更有利于关注价值交付，对这一主题产生了相反的矢量。实际上对于敏捷团队的组织，几乎普遍接受的方式是围绕特性的。如下图所示。
特性团队方式的优点也非常明显：团队可以形成对实际领域和系统使用方式的专业知识，而且通常可以加速任何特性的价值交付。这种方式的开销更少，因为在对特性的实现中，多支团队不必来回传递待办事项条目。而且在团队之间的相互依赖少很多，计划工作与执行也更简练。
与核心技能对应于技术栈中某一层形成对比的是，特性团队的核心能力对应于某个特性(或特性集)。团队的待办事项被简化了，在任何时间只有一到两个特性，这样必然可以促进高增值特性的快速交付！
也有一些其他作者支持以特性为焦点的方式。例如Highsmith写道：
基于特性的交付意味着工程团队将构建最终产品的特性。
当然，这并不是说团队本身必然是“按特性组织”的，因为所有工程团队到了最后都是为最终产品构建特性，虽然他所说的可能含有某种合理推断。其他人—包括Larman和Vodde，更直接(而且坚决)地提倡特性团队作为组织敏捷团队的最佳方式，他们指出：
特性团队是一种长期、跨职能的团队，能够一个接一个地完成一些端到端的顾客特性。其优点包括提高价值产量、方便知识学习、简化计划、降低浪费….
Larman和Vodde还认为应该“避免构件团队”。不管怎样，他们也指出了采取特性团队方式的若干难题，包括需要更宽泛的技能和产品知识、对代码的同时访问、共享设计职责、以及在实现复用和基础设施工作中的困难，而且还有围绕边界的组织对齐造成某些团队成员错位的可能性。
有时候界限是模糊的
即便有着这样的建议，我们也必须承认特性和构件都是抽象概念，它们的界限并不明确，一个人设计的特性可能是另一人的构件。而且有时候，单一特性最好被实现为独立的、面向服务的构件。
举例来说，TradeStation Securities构建一个在线交易系统，其中“记录”是一个关键的交易者功能，由少量集中的敏捷团队一起在“记录”功能上工作。表面上看起来这是特性团队的一个良好示例，因为记录是该系统的主要特性。
在开发新的在线交易功能时，如“外币兑换交易”(Forex)，必须添加新的记录功能。然而驱动这一新记录功能的是一些主要构件，如流化数据、账户管理、与外汇交易市场的交换接口。是应该把新特性的价值流描述为“通过专门的记录功能完成与外汇交易市场的所有交易”吗？如果是，很明显应该产生垂直特性流，而且可能要重新组织团队，从各构件团队吸纳某些成员并针对外汇交易市场的交易创建新的垂直特性团队。或者是否把新特性描述为“Forex交易”加“Forex绘图”？这种情况下的绘图团队是否已经有了适当的组织？这种记录功能是特性集还是构件呢？或者是二者？对这种状况起个什么名字真的重要吗？
即使认为其称谓是可以明确的，特性团队总是最佳选择吗？Keith Black(TradeStation Technologies的副总裁)写道：
在线交易要求在许多不同层次上有着相当深度的专业技能和行业知识，我们没有办法对来自所有构件领域的成员合理地形成特性团队。
因此，在我们向敏捷转型中，我们首先是围绕构件团队进行组织，在成熟之后，我们现在针对特殊情况组建特性团队。虽然特性团队在推动一个计划直到完成中是出色的，但是某些情况下它们就不合理。例如，有二十支特性团队而且他们都依赖某个公共构件，比如一个时间关键型的联机事务处理引擎，让20支不同的团队都参与到这一关键构件是不明智的。相反，可以选择使其中的变更由单一团队控制，由该团队代理20支团队的需要，并通过对具体特性作出修改确保其他团队不危及他们不了解的区域。
向特性团队倾斜
鉴于每种方式的优点与缺点，答案并非一直都那么明显。但是考虑到敏捷对直接价值交付的焦点，可以向特性团队适当倾斜。正如Mike Cottmeyer指出的：
我倾向于从特性团队开始，只在必须的情况下才转向构件…但这种决定是基于特定状况的。
为了做出这种决定，将必须分析你们的技术多样性…你们系统设计的如何…使用什么工具来管理代码基…你们团队的规模与技能…团队是如何定位以及分布在哪里…还包括你们的基础设施自动化的品质。
必须认真研究要把特性团队分解到什么程度…到了某种规模特性团队会瓦解。伸缩到这样的程度是我们必须现在处理的吗，还是可以等待？
