使用用户故事进行计划
为主要风险的处理设定最终期限
使用用户故事进行计划使得开发团队可以经常性地交付对用户有价值的功能、快速响应市场机会、获取竞争优势。但是这其中也有潜在的陷阱和风险。
如果屈从于对外展示进度的压力，团队有可能更偏向开发简单的任务，而延缓具有风险的任务。项目管理更多聚焦跟踪开发活动，而不是处理风险。
为了避免这样的陷阱，开发团队需要和业务部门共同设定明确的期限、以可持续的节奏来处理重要的风险点。
Alistair Cockburn 建议团队定期在“学习模式”（应对主要风险）和“交付业务价值”模式之间进行切换。特别是在项目开发的早期，团队需要更加专注于解决风险。
团队可以预先决定什么样的交付物可以表明某个主要的风险已经被处理掉了，然后为这样的交付物设定一个时间期限。这样的交付物可以是一部分功能的完整实现、一个可运行的原型或者一个概念设计。
通过设立具有层次结构的Backlog也可以帮助团队和业务部门避免从待处理任务中永远无脑地选择“下一个”，而不去处理重要的风险点。有了层次结构后，团队可以在比用户故事更高的级别上决定优先级，例如挑选更大范围的业务影响（Impact）。因为为了交付具有更大范围业务影响的用户故事，必须要在处理风险和交付价值之间进行更好的权衡。（要理解这里的Impact，需要借助Impact Map这个分析工具）。
不要使用诸如速度表或者燃尽图这样的活动度量来衡量经度。这些工具只能显示人们有多忙，但是无法显示他们是否在做正确的事情、甚至是否在创造有价值的东西。应该创建一个关于期望中的业务价值的模型，然后衡量和报告趋向这个模型的进度。
使用有层级结构的backlogs
伪迭代开发的最大陷阱之一是“故事卡片地狱”（story card hell）（有太多数量的卡片需要管理和跟踪）。故事卡片地域给人一种整个开发过程在以迭代的方式展开的错觉，而实际上团队只是在（盲目）追随几个月前设下的详细计划。具体来说：
- 交付团队浪费了太多的时间跟踪和管理不必要的事务，产品经理疲于奔命。
- 当市场机会发生变化时，业务持份者面领严峻的两难处境：根据变化的环境调整计划则意味着抛弃大量的沉没成本并且打破承诺；继续遵循原有的计划则可能最终交付过时、无用的功能，或者延迟更重要的任务。
- 需求蔓延和不必要的工作很容易被隐藏在大量的事项中。面对大堆的卡片难以逐一衡量它们的价值和目标。
很多人是在业主的逼迫下落入这样的陷阱。一方面既然要执行一个迭代式的过程，那么在一开始就定义全部的范围是无意义的；另一方面业主需要跟踪成本，并且不断索取详细的估算。
缺少大图景的可见性是业务持份者预先对几十、几百的用户故事索要详细的估算和承诺的关键原因。
不要尝试将所有的大项目全都分解为小项目，因为这将肯定招致敏捷计划的失败。
在Backlog中的项目应该是属于不同层次的。尝试在完成前一个高层次项目的所有下层故事前不要去分解下一个高层次项目。这样可以以描述大图景的项目（比如Epic ）为单位来跟踪、讨论和报告进度。
层次状的Backlog使得不同的业务持份者可以在不同的信息层次上讨论、汇报和分析。
层级的例子：
- 业务目标的大图景；
- 为了实现大图景而需要的小范围的业务变化；
- 支持上述业务变化的软件交付物（功能），例如从竞争对手的文件格式中导入数据，或者移动端数据预览；
- 能够独立交付的小功能片段，例如访问竞争对手系统的文件、导入某种数据格式、移动数据预览页等。
在我们开始某个业务目标的开发工作前，甚至不会试图取识别相关的可能的业务变化。在开发计划中只有这一个业务目标、没有它下面层级的任何东西。
保持Backlog中处于每个层级的项目的数量尽可能小——不超过当下的计划和交付工作所必须的程度。在使用的项目计划和管理工具中应该使得不同的层级明显可能，比如使用不同的颜色、不同的泳道等。
根据影响对故事进行分组
一种组织层级化Backlog的方式是使用“影响图”（Impact Mapping）。
影响图是一种可视化地表示软件功能如何与业务目标和假设相联系的思维导图。影响图有四个级别：
- Goal: 业务目标
- Actor: 在达到业务目标过程中牵涉到的用户、业务部门或其他角色。
- Impact：对用户或业务部门的影响，这种影响有益于业务目标的达成。
- Deliverable：将导致上述影响的用户故事或更高级别的交付物（例如Epic）。
该书作者写有一本小册子专门介绍“影响图”： Impact Mapping: Making a Big Impact with Software Products and Projects