想要撰写优秀的用户故事是有一些准则的。比如开始时为了却确定故事，我们从每个用户角色使用系统的目标开始考虑。该用户为什么要使用系统，他希望系统为他做出何种结果？这都是用户故事需要考虑的。分割故事时，试着让故事能够贯穿应用程序所有层面，试着让一个故事够长但必须完整，并不要让故事太早涉及系统行为，如用户界面等。在编写故事也要考虑到用户角色。让客户而不是开发人员编写故事。即用户故事并非开发人员的故事，他必须依赖，来源于用户的实际场景，是事实而不是胡乱编写。
在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级。 故事应该以明确的顺序排列（第一个、第二个、第三个，等等），而不是利用诸如“非常高、高、中等”模糊顺序的分组。 故事的优先级由客户确定，但也要考虑开发人员的想法。 使用速率将以理想日为单位的估算转换成日历日。 估算团队的初始速度是很有必要的。 开发人员负责提供信息给客户，帮助客户排列故事优先级，负责权衡基础需求或架构需求与其他客户需求之间的平衡。并负责为项目争取一定的时间缓冲。客户负责排列故事优先级，表达发布期限。
阅读完这章之后我才理解了故事优先级的重要性。故事完成肯定有风险，例如有全新的算法，故事完成肯定会推迟，我们这时肯定要根据故事的优先级来决策开发顺序，以减少超出预期的意外为项目带来的损失。
完成一个任务或故事所花费的实际小时数对当次的速率没有影响。 每日燃尽图在迭代中十分有用，它展示了迭代中每天剩余的小时数。 设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。 开发人员负责尽量在完成一个故事后再去做下一个故事。我们更希望看到更多已完成的故事，而不是较多未完成的故事。 项目经理应了解图表何时被需要并及时的提供这些资料。 客户应了解开发团队的速率，决策判定实际速率和计划速率的差别和是否需要调整计划。