Have  developers provide the “I want ” Part of user stories  when: business users trust the developement team

在uSwitch的团队和他们的商业用户协作来定义用户故事。商业用户明确名为Stakeholder的用户故事部分和期望的利益，开发团队提出来那一部分的解决方案。 在标准的用户故事格式中，这意味着商业用户为”as a XX” 和”in order to”提供了一个方向，而开发团队则完成了”i want -”的部分。

为目标得出正确的范围的一个方法就是将解决方案的责任牢牢的放到开发团队上。【A great way to obtain the right scope for a goal is to firmly place the responsibility for a solution on the development team.】。

假如你足够幸运到能够对项目的范围进行掌控的话，确保开发和测试团队能够参与到范围确定的讨论中，并且将精力放到能够实现明确的目标的建议方案上。这回消除大量的后续的不必要的工作，为Spec的协作提供了一个更好的舞台。

Collaboration on scope without high-level control

---

对于大多数一同工作过的团队，尤其是在大公司的团队，范围有时候是从较高等级传递过来。许多团队认为当他们维护的仅仅是大系统的一部分的时候是不可能得出商业目标的。即使在这样的情况，理解商业用户希望达到的也能帮助你关注项目确实关心的。

当你对项目没有较高层级的控制的时候，下面一些有效率的在项目范围上协作的提示：

Ask how something would be useful

---

Stuart Ervine 在一家大型银行的办公支持系统工作，这个系统支持用户以树状结构管理合作管理。这是一个大型系统中一小部分的绝佳例子。即使这样，他们也能够从任务中出来已得到真正的需求信息。

Ervine的团队的任务是改善层次结构的效率，听起来像是一个没有任何利益的纯粹的商业需求。但是这个团队不能在那么那部分执行任何性能操作相关的内容，因为任何改进都会涉及到框架的变动。

他们问用户怎么样改进效率会比较有效。最终发现出现性能的地方是因为用户手动的执行在树状结构中执行复杂的计算并且添加客余额信心。他们为了添加账户余额信息，会在用户界面打开iahe关闭大量的合作伙伴节点。这是一个比较慢而且容易出错的计算过程。

没有优化层次结构的性能信息，团队为用户自动化了计算过程。这使得结算过程变得非常迅速而且极大降低了错误的可能。这个解决方案带来了更好的结果，和最初要求的相比也更加Cheaper.

和在性能特性规范上相比，我们应该更多的了解关于特性为什么会在更高级别起作用。这会将我们引向真实的问题所在。【Instead of a technical feature specification, we should ask for a high-level example of how a feature would be useful. this will point us towards the real problem.】

在磨平沟通的鸿沟方面，我建议问一下问什么并且重复同样的问题知道答案开始涉及到金钱。我现在认为要求列举一个特性为什么是有价值的例子是得到同样结果的更好的方式。问为什么有些事情是需要的就像将他人放到一个防御的位置，尤其是在大的组织机构中。问为什么有些事情会有用会开启一个不会挑战任何人的权威的讨论。

Ask for an alternative solution

---

除了要求一份事情是怎么回事的例子比较有用外， Christian Hassa建议通过讨论一套额外的方案也能够取得真实的商业目标。 Hassa解释说：有时候，人们坚持解释一个特定的功能特性会有什么样的价值（即使你要求给出一份示例也是如此）。深入一步，我要求他们能够给出一个示例，并且说明什么是需要他们做的不同的事情，假如系统不提供这个特性的话。 通常这会帮助他们表达出来已有功能特性的价值。

一个能够从商业视角发现额外的选项的好策略是要求提供一个不同的解决方案。【A good strategy for discovering additional options from a business perspective is to ask for an alternative solution】。

要求提供一份不同的解决方案能够是要求某个特性的客户重新思考提议的解决方案是否是最佳的一个。也会启动一个同发布团队的不同的方案的讨论。