概念到范围确定
如果你充分理解了项目的目标和项目要交付的业务价值，突破条件1-1就实现了。具体来说，你和关键的利益相关者一致同意项目的愿景。在这个阶段你不需要正式的模型(虽然它们可能有帮助)，而是需要对待解决的问题达成一致，以便让团队进行下去。我们认为一张丰富的图就足以实现这一突破。当然，大家要同意它准确地解释了问题。
范围确定到工作调研
如果你确定了合适的工作范围，你的项目将在这个范围内交付业务价值，突破条件1-2就实现了。也许项目迭代到后面的活动时，这个范围可能需要稍作调整，但你必须从某些确定的、不模糊的想法开始。我们强烈建议画一张工作上下文范围图来满足范围确定的突破条件。除非你的范围是很小的工作，否则就应该对它进行划分。对于工作调研活动来说，对业务事件的响应(业务用例)是最方便的工作单元。
业务用例根据它们对业务的价值来排列优先级，很自然，你先从优先级最高的业务用例开始。也许最好将突破条件1-2看成是已经从待选列表中选择了优先级最高的业务事件。这个列表代表了你的工作的待完成清单。
如果你迭代回到这项活动，你可能希望重新排列这个列表的优先级，以反映业务优先级的变化，希望包含一些新的业务事件，它们是前面迭代之后发现的，或者因为新的机会已经出现，所以最好是调整你的优先级。在任何阶段你都可能需要回头来复查工作的范围，我们这里提到的变化可能随时会影响工作的范围。让你的知识可见，并分享这些知识，这样人们就很容易看到变化带来的影响，并快速响应它。
如果你已足够了解所选择的业务用例，能够决定最佳的产品范围，突破条件1-3就实现了。此时，你知道选择的BUC所遵守的业务规则，并且你已充分调研了它的功能如何适合整体的工作。知识在这里很重要，但也需要将知识分享给团队成员和业务利益相关者。对于迭代项目轮廓来说，你可能与本地的小团队一起工作，所以我们认为可见的显示可能是分享信息的最佳选择。你可能选择在墙上保留信息，形式可能是告示、场景、业务故事卡、即时贴或文档，让积累的工作知识可见。我们发现经常给墙拍照是聪明的做法。
当然，这种技术不会适用于所有的迭代项目，因为组织机构的限制条件有时候会强制你将知识转换成规定的文档。要点是避免进行知识转换(也就是说生成文档)，除非这不可避免。重要的考虑在于，你已经有了必需的知识，而且整个团队都能看到，能理解。
如果你选择从业务用例直接跳到为BUC定义需求，突破条件I-4就实现了。这些需求的形式可能是用户故事，因为故事常常意味着产品边界。突破条件1-4与1-3类似，但还需要知道用户的基本情况，他们将使用你构建的这部分产品。而且，你需要明白解决方案必须满足的限制条件。
如果你已经为选择的业务用例定义了自动化的范围，突破条件1-5就实现了。到达这一点意味着你已获得BUC的知识，并和业务利益相关者一起，决定实现多少自动化可以获利。我们在第8章中更深入地探讨了这个决定。
你可以用多种方式展示产品范围的决定。我们发现用图形模型来画出产品边界是有效的(活动图或其他模型)，或者画出接口草图(这个主题的更多内容参见第8章)。
有必要将产品用例的决定回溯到BUC。这种联系让你有效地在不同思想间迭代，并根据成本来评估相关的价值。
如果你对于一部分要改进的工作获得了足够的知识，能够为它建立软件解决方案，突破条件1-6就实现了。不论你选择通过用户故事或原子需求(或其他形式)来记录这种知识，你都应该记录下功能需求和非功能需求，这些需求都是改进这部分工作所必需的。
原子需求或用户故事有一些重要属性，它们是理由(存在某种需求的原因)和验收条件(让测试人员能确定产品满足需求的测量指标)，第12章将对它们进行讨论。包含这些属性是说为什么需求很重要，所以让设计者和开发者在构建产品时做出最佳选择，并让他们决定测试需要多少工作量(与精彩的功能相比，理由很弱的需求受到的关注较少)。