成本/收益矩阵（Cost/Benefit Matrix）

对于组织为当前项目付出的成本和得到的收益，我们会有一个估算。该工具会告诉大家：这个估算的不确定性程度如何。在项目早期，成本会有一个不确定性圆锥【原注5】，随着项目推进，该圆锥的顶角会越变越窄。收益的不确定性也很大。只要估算范围正确，在成本和收益方面的不确定性算不上大问题。成本和收益都应该展示出三个水平：乐观情况、可能发生情况、悲观情况。例如：

表格中每个单元格的数字是收益减去成本之净差。

该项目应该被视为高风险项目，因为有明显的风险表明组织可能在上面赔钱。如果一切顺利的话，也许有其他驱动因素能够保障投资和回报。

对项目进行成本/收集分析主要是管理层的责任，但是在财务方面的目标和驱动因素应该分享给团队。

明确说出愿景

借助这些工具，团队可以明确了解项目的目标和方向，知道为什么要展开当前项目的工作。

准备产品愿景，是一个项目非常重要的起点，并为团队在项目进行中保持正确的方向和重点提供保障。之前工作组讨论中产生的墙件（wallware）【原注6】应该出现在团队的工作环境中，为项目工作的任何人只要一抬眼可以看到项目的驱动因素和目标。撰写正式的文档来综述产品愿景，这样做也很有价值。要知道：文档只有一部分价值，另一部分价值来自于团队在产生愿景的过程中对产品和项目的共同理解。

如果开发产品的团队分散多地，应该在产生产品愿景时，把他们聚在一起。这可以塑造出“一个团队”的文化，并对他们分开之后的沟通有帮助。

如果有成员在愿景产生之后加入团队，必须要有人带着他们把项目章程过一遍，这个人还得是参加过工作组讨论的。唯其如此，新成员才能理解工作背后的驱动因素。

产品愿景的管理是产品负责人的责任，他负责将业务需求带给项目团队。如果在项目执行过程中，环境发生变化，愿景无法达到，或者组织的目标和驱动因素发生作用，使得项目无法在其基础上交付，项目应该停下来，并重新评估。产品愿景的变化，常常是组织生态系统发生重大变化的证明。

产品路线图

产品路线路是一个列表，列出为了达到产品愿景需要交付的关键功能和特性。当项目需要延伸到产品的多个版本发布时，产品路线图是非常重要的。如果只需发布一个版本，那么产品路线图和发布规划没有区别。

产品路线图基于时间的视角，来看产品的预期交付周期。它是高层面的规划，由产品负责人和项目经理维护，并随时间发生变化。

产品路线图要定期与产品愿景互相验证，并让团队和其他人知道产品各个组件可能的发布日程。

产品路线图处于特性和“史诗故事（epic）”的层面，用户故事不包括在内。

产品路线图要通过可见大图标来展示重要的里程碑、功能特性和目标发布日期。发生变化时，可以从路线图中加入、移动或是移除一些条目。

下图是一个真实项目的路线图实例，展示出六周之内的两个版本发布周期：

（图片来源：新西兰，Livestock Improvement Corporation）

该路线图位于团队环境的过道中，起到信息辐射器作用，让所有工作在同一个项目组的团队们都能看到，其他任何对项目感兴趣的人也可以参考。产品路线图为从事同一个版本发布的各个团队们提供上下文。

版本发布计划（Release Plan）

版本发布计划展示出产品当前发布版本要交付的特性，其中包括当前大家达成一致意见的、经过排序的史诗故事和用户故事。版本发布计划基于预期的团队速度，并告诉大家当前版本中包括哪些对产品的共同理解。

初的产品规划活动要由团队和产品负责人共同完成，产品负责人要提供当前版本的目标。一个版本发布包括一系列迭代，团队在这些迭代中完成工作，交付一系列特性，为组织提供可度量的价值。一个迭代中要完成的一系列功能特性构成了版本发布的条件，并且是当前发布版本要交付的产品整体功能特性的子集。