举个很简单的例子——迭代中有个故事点要开发一个从外部捕获数据源的web service。故事点可能对所捕获数据的用途只字未提。在这种情况下，除非开发人员知道这些数据在下游产品中的用途，否则他不可能很好地为这些数据设计出持久性策略。如果这些数据需要进一步的转换，它就需要经过某种处理——而如果它只是以报告为目的的，可能就要用另一种完全不同的方法了。
这个层面的认知只能通过花时间来学习产品战略方向、预期用途、目标用户和使用期限。
图一：故事点的战略性视图
Deming的这个要点还强调了有效沟通的必要性。通常商业利害关系人并不花时间来讲解产品的用途，而工程师们也懒得弄清楚这些。因此团队常常无休止地纠缠于纷繁的目标之间无法自拔，最终只能以低质量的、不满足公司真正需求的产品来收场。
在这点上有两个最佳实践能帮上忙：
* 预先制定一份较粗的、涵盖整个项目的计划——这可能看起来和敏捷理论有些背道而驰，但实际上并不。敏捷原则只建议不要预先做细分到任务层面的计划——但它并不是劝阻任何层面的计划。能展示里程碑并列出产品所有主要特性的、较粗的计划有助于为单个故事点提供必要的上下文环境。
* 将产品愿景写成文档，并经常和所有的利害关系人沟通确认。愿景文档不需要很详细——但它应该包括足够的信息，能够清楚地解释产品背后的战略、预期用途和发起者的期望。随后团队要特别重视在项目过程中定期地回顾一下愿景文档，并做一些必要的航向修正以保持与愿景同步。
