这是本次阅读笔记第三篇，也是我开始用户故事与敏捷方法一书中对第二部分的理解。
针对第八章估算用户故事
我了解到，故事点，可以用户理想日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。 以团队估算 客户和产品经理可以参加，但他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。再使用故事点的时候，我们要记住使用故事点 我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必保证每次迭代的故事点的度量是一致的。
同时我们要谨记开发人员职责：
1.负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
2.负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。
3.负责以团队估算。
4.负责估算应与其他估算一致。
在第9章发布计划中，我们就有必要知道客户预期的大致发布日期和故事的相对优先级。故是要有明确的顺序排列，而非模糊含糊不清，例如：第一个，第二个故事。
诸如：高很高，非常高，一般这类字眼模糊不清，最好禁止使用。故事的优先级应该由客户确定，但是开发人员也要有自己的想法。开发人员要及时提供信息，有时包括基本的假设和可能的替代方法给客户，这样才能更好地帮助他排列故事的优先级。同时，开发人员还有很多的职责，例如负责在基础性需求活着架构性需求与其他客户端之间取得权衡，避免不切实际的提高基础性需求或架构性需求的优先级；负责诚实地表达发布期限；负责理解理想日和日历日的不同等等。