00.估计值不是由开发小组中的单个人建立的。敏捷开发小组并不是依靠某一位专家来进行估计。除了众所周知的将要做次工作的人对工作做出估计比其他人做出的更准确意外，最佳的估计是由包括将要作词工作的人在内的小组合作得到的。
01.史诗(epic)：对于还不确定是否需要的功能（在投入过多的投资之前，需要首先对它进行初步的成本估计）或者在最近不会实现的功能，写一个更大型的用户故事往往可能更恰当。根据规模所称史诗，往往本身就是一个主题。
02.主题(theme)：一组相关的用户故事可能会被结合在一起，并在估计时和发布规划中都被当作一个单一的实体。
03.规划扑克吧专家意见、类比和裂解结合到一种令人愉快的规划方法中，可以产生快速但可靠的估计。
04.对每个要估计的用户故事或者主体，由一个协调人读出它的说明。通常由产品所有者或者一名分析员来担任协调人。
05.再次说明，估计的重点不在于绝对的精确，而在与合理性.
06.只要每个人都记住我们最感兴趣的是小组的长期平均速度，而不是速度在某次迭代中的升高或降低，这样做就不会有什么问题。
07.无法学习才是真正的失败。从每一个重估的用户故事中学习，然后把取得的经验转化为成功的推动力。
08.记住故事点和理想日是对功能规模的估计，可以帮助您知道何时进行重估。
09.这自然取决于有多少对象需要估计、小组的大小以及产品所有者简洁地阐明所有需求的能力