1.让整个小组参与。
特定活动的主要职责可能会落在某个人或者某个分组身上，例如确定需求的优先级主要是产品所有者的职责。但是，在最求可能具有高价值的项目时，要让整个小组 参与进来并做出承诺。例如，我们可以在一条建议中看到这一点，这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个 小组做出的估计才是最好的。小组成员分担的职责越多，小组可以共享的成功也就越多。
2.在不同层次上进行规划。(产品Backlog->Spring Backlog->任务->每日计划)
不要错误地认为发布计划会让迭代计划没有用，反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。
3.使用不同度量单位，让对规模和持续时间的估计保持独立。(规模和工作量的关系，故事点)
让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模，再使用速度把规模转换到持续时间是完成这一工作的好办法。
4.用功能或者日期来体现不确定性。
没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的，就把不确定性表示为一个日期范围（“我们会在 第三季度完成”或者“我们会在7~10次迭代中完成”）。如果日期是固定的，就需要表示在要交付的确切功能上的不确定性（“我们将在12月31日完成，产 品至少会包含这些新功能，最多可能只会再包含那些新功能”）。不确定性较大的时候，就使用较大的单位（例如迭代、月，季后是季度）。
5.经常重规划。(滚动计划)
利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定，就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。
6.跟踪进度并沟通。
有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。
7.承认学习的重要性。
由于项目既是向产品增加新能力，也是产生新的知识，所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要，会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况，会调整对进度率的期望和希望采用的方法。
8.规划具有适当规模的功能。(故事点的粒度问题，短周期迭代)
在不久的将来（接下来几次迭代中）就要增加的功能应该分解成相对较小的用户故事–通常就是需要1~2天，最多不超过10天的事项。我们最善于估计规模处于 一个数量级内的工作。让用户故事都处于这一范围内，可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事， 让大多数小组合一在一次迭代中完成。当然，在较长时间的项目中，使用小用户故事会很费事。为了平衡这个影响，如果您要建立的发布计划覆盖的时间范围超过了 未来的 2~3个月，也许可以编写一些更大型的故事（称为史诗）或者使用主题，来对时间更遥远的工作进行估计，从而避免过于提前把大故事分解成小故事。
9.确定功能优先级。(计划安排之基本，规模和优先级)
按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本，还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一 个显著的风险的可能性，往往就足以保证先开发某个功能的合理性。与之相似，如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识，也应 该考虑尽早开发这个功能。
10.把估计和计划建立在事实上
只要有可能，就把您的估计和计划建立在现实的基础上。确实，有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是，只 要有可能，就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候（我们还没有开始处理它）， 也相当容易知道我们已经完成了100%的时候（产品所有者的所有满意条件测试都通过了）。在这两者之间就很难度量了–这项任务完成了50%还是 60%？由于这个问题太困难，最好还是坚持您所知道的：0%或100%。
11.保留一些松弛度。(项目进度和人员缓冲)
尤其是在规划一次迭代的时候，不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样，如果将所有人的时间都规划成满负荷工作，开发小组的进度也会减慢。
12.通过前瞻规划协调做个小组。
在涉及多个开发小组测项目中，应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代，可以规划和调节小组间的依赖。
