并不局限于敏捷团队
不是只有敏捷团队才可以从协作制定需求说明中获益。在Bridging the Communication Gap一书中，我建议在更为传统的结构过程中应用类似的实践。
英国Sopra集团的高级测试顾问Matthew Steer帮助一个大型电信公司的第三方离岸软件交付伙伴实现了这些实践。他们意识到项目需求定义不明确后，决定作出改变。Steer比较了实施实例化需求说明前后一年的交付成本。不出意料，这些项目使用瀑布方式开发，没能达到零缺陷的级别，但是这些改变“提高了上游缺陷的发现率，减少了下游的返工和成本”。Steer说：
我们在软件生命周期早期发现的很多缺陷，传统上要到晚期才能发现，这足以证明这个方法行之有效。缺陷数在生命周期的晚期有明显的下降，而在早期则有所提升。
最后结果是，交付成本仅在2007年就节省了170万英镑。
减少返工
一般来讲，频繁地发布会促进快速反馈，使得开发团队能够更快地发现错误、修复错误。但是快速迭代并不能避免错误。通常情况下，团队实现一个功能时会有三四次反复。开发人员称，这是因为客户在拿到产品试用前并不知道自己想要什么。我并不这么认为。使用实例化需求说明后，通常团队第一次实现的就是客户所要的，无需返工。这可以节省大量的时间，并使得交付流程更具可预测性、更加可靠。
位于伦敦的英国天空广播公司（British Sky Broadcasting）的天空网络服务（SNS）部门负责宽带和电话的服务配置（provisioning）软件，它的业务流程和系统集成都极为复杂。该部门由6个团队组成，他们使用实例化需求说明已经有好几年了。据他们的资深敏捷Java程序员Rakesh Patel说：“当我们说交付时，确实是能马上交付的。”并且该部门在Sky公司内具有很高的声望。Patel曾和其他公司的团队一起工作了一段短暂的时间，他对两个团队做了比较，他说：
他们（其他公司的程序员）每次在迭代（sprint）快要结束的时候才把软件交给测试人员，测试人员总是发现问题并退回给程序员。而在这里（Sky），我们不会如此反复。如果有错误，我们会编写一个测试，而后在开发过程中使测试变绿——要么通过，要么不过。我们可以当场发现问题。
其他不少团队注意到了返工的大量减少，其中包含LeanDog，它为一家美国大型保险机构开发聚合应用软件。他们的应用软件为很多大型主机和基于Web的服务提供统一的用户界面，而且由于拥有来自全国各地的大量项目干系人，该软件变得更加复杂。最初，在需求方面，该项目遭受了很多功能缺失的问题。Rob Park是LeanDog里帮助团队转型的敏捷教练，他说：
刚开始理清头绪时，我们需要澄清需求，而后我们发现不得不切实做些改变。
该团队实施了实例化需求说明，结果需求说明改善了，返工也减少了。据Park说，虽然当程序员针对某个故事卡开展工作时，有些问题还要向业务分析师咨询，但是“问题已经大为减少，而且重复性工作少了，只剩下不同的问题”。对他来说，实例化需求说明最有价值的方面在于“当着手实现一个故事时，你可以领会它的意图，并了解它的范围。”
很多团队还发现在开发周期的起始阶段，使用实例化需求说明会让需求更加精确，这样管理产品功能清单（product backlog）会更加容易。例如，能够尽早识别太含糊或有太多功能缺失的故事，这样可以防止以后出现问题。如果没有实例化需求说明，团队经常要到迭代中期才发现问题，这会中断流程而且需要耗费时间重新讨论——在大公司，决定功能范围的项目干系人往往无法轻易预约到。
实例化需求说明能帮助团队建立一个协作制定需求的过程，这可以减少迭代中期的问题。此外，实例化需求说明适用于短迭代，并且不需要花费数月的时间来编写冗长的文档。
Ultimate软件公司位于佛罗里达州的韦斯顿，对于它的全球智能管理（Global Talent Management）团队来说，减少返工是一个主要的优点。协作制定需求说明在专注开发工作方面有着显著的影响。据Ultimate软件公司的资深测试开发工程师Scott Berger所述：
在团队认可一个故事之前，与产品负责人一起审核测试场景可以使工作小组（产品负责人、开发人员和测试人员）澄清模棱两可或缺失的需求。有时，会议结果甚至会把故事给撤销了，例如，测试场景会揭露出系统隐藏的复杂性或相互矛盾的需求。有一次，进行这样的讨论之后，大家做出的决定是几乎重新设计整个功能！产品负责人获得了重写和重新分割需求的机会，而不是在开发进行之后，中途停止或取消该故事。通过举行这些会议，我们发现自己的生产力和效率都提高了，因为减少了浪费，而且模糊和需求缺失的程度降到了最低。同时还让团队对预期达成了共识。
大多数团队显著地减少或完全消除了由于误解需求或忽视客户的期望而造成的返工。本文所描述的实践，可以让团队更好地与商业用户打交道，并确保大家对结果达成共识。
