计划，为了更少的开发
故事地图帮助大型组织建立共识。贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。
大型用户故事地图解析：1、故事地图的主干在顶部；2、地图要涵盖整个发布计划；地图要涵盖贯穿多个用户和系统的叙事主线。
提前发现可能造成损失的潜在风险是好事而不是坏事
需求范围并没有蔓延，而是我们对需求的理解更深刻了。
要做的事情太多，如何排定优先级？聚焦于系统外的预期成果来决定系统内需要什么功能！！聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向【针对MVP（最小可行产品）计划】。聚焦于特定的目标成果，这是排定开发工作优先级的秘密。为成果排定优先级，而非功能。
寻求最小的可用发布集。一个可能的方法是，识别出哪些是基础功能，哪些是降成本功能，哪些是搅局功能，哪些是差异化功能。
MVP到底是个什么东东？
- MVP是指可以产生预期成果的最小产品发布
- 最小可行方案是指可以产生预期成功的最小发布方案
- 最小可行产品是为验证假设而做的最小规模的实验
对这个概念的理解至关重要。首先，MVP本身必须是个独立的软件，可以直接交付给用户使用，并能产生价值的。其次，最小本身是个非常个性化和主观的词，如何确定最小？需要首先搞明白这个最小针对的是哪些用户，这些用户需要通过软件来达成什么目标。但无论如何，最小还是存在很大的猜测成分。既然是猜测，那就很可能猜错了。那如何降低猜测带来的风险呢？需要回答两个问题：1）最大胆，风险最大的假设是什么？哪些是最不确定的？2）为了消除假设或者风险，需要哪些真实的信息？因此自然而然会得出一个推论：能不能通过快速调整策略，聚焦于学习，通过快速验证第一个MVP的假设？就是说，能不能通过设置更小规模的实验和原型来验证我们对于最小和可行的假设呢？联想到演进式架构中提到的假设驱动开发，和这里的用户故事正好可以呼应。
一组好问题，实际上项目也是这样来对待需求的。
- 需求内容是什么？
- 客户是谁？哪些公司会采购这款产品？
- 用户是谁？哪些人会用到这个产品，用这个产品来解决什么问题？
- 购买和使用的动机是什么？解决了哪些客户和用户当前无法解决的问题，使用之后又能获得什么样的收益？
- 为什么要开发这款产品？如果开发出来并成功销售，公司又能从中获得什么收益？