1、敏捷的一项重要原则就是项目进展和问题交流的透明性，只有这样才能保证对问题做出及时调整，功能小组可以根据需要采用不同度量数据；提醒一点：决定采用哪些度量数据以符合团队和产品相关人员的要求，需要一段时间去体验。因此，如果你对敏捷不是很了解，或者你正在带领一个新团队，建议你选取所有的或者大部分敏捷度量数据，然后逐步去除那些对团队不必要的信息。

例如，在我们的项目中，某些功能团队在一个Sprint中使用燃尽图来跟踪进展情况。有些则不使用燃尽图，因为他们觉得每日站立会议上所提供的信息，足以用于跟踪项目进展和进行调整了。同样的，有些功能团队可能需要使用团队生产力图辅助他们来进行估算下一Sprint能够完成多少任务，而有些团队则不需要这种方式。

2. 很多独立功能小组分别负责多个主题，这些主题集合在一起就构成了价值主张，而这些价值主张帮助达到特定产品发布所要实现的商业目标

以整个部门的完成标准为基本标准，每一个功能小组还会会有一个自己的一个完成标准，小组通过自己的反省Retrospective会议，不断地演进自己完整标准。对于功能小组，我们为实现用户故事定义一套完成标准。

单元测试是由开发人员设计并实现为自动化测试，针对系统中加入的单个低层API。单元测试会与产品代码一起签入到TFS版本控制系统。

验收测试和功能测试由测试人员根据项目经理的功能说明书来编写的。

验收测试用例在所有测试用例中优先级最高，通常为1级（P1），它们覆盖了功能说明书中描述的最基本/核心的用户场景。验收测试用例保证了产品实现的功能达到了用户故事描述的设计。通常情况下，功能说明中每个用户故事对应一个或两个验收测试用例。

除了最基本的用户场景之外，产品功能的其它扩展或临界情况则由功能测试用例来覆盖。测试人员编写的测试计划包含了功能测试用例。这些测试用例要根据所覆盖用户场景的重要性以及用户可能使用产品的方式进行优先级划分。根据以往的经验，一部分功能测试用例会被自动化，其余的用例则作为手动测试。手动测试的原因有很多，例如：自动化测试技术的局限、时间和资源限制等。