优秀用户故事准则 从目标故事开始 切蛋糕 技术人员习惯将大故事按照技术路线分割，这种做法的缺陷是，没有一个故事是单独对用户很有用的。而应该保证每个小故事都提供某种程度的完整的功能。 编写封闭的故事 一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某个任务。 卡片约束 对于任何必须要遵守而不需要直接实现的故事，在其故事卡上标注“约束”（constraint） 比如 系统必须支持最大50个并发用户的峰值。 尽管约束卡不需要做估算，也不会像普通卡那样被安排到迭代中，但可以有验收测试。 根据实现时间来确定故事规模 不要过早涉及用户界面 有些需求并不是故事 如果需要，可以放心使用用户故事以外的其他形式来表达某些需求。例如，用户界面参考通常是以有很多截图的文档来描述的；通过文档来定义重要系统间的接口等。 在故事里包括用户角色 如果项目团队已经识别出用户角色，那么在编写故事时就要使用它们。比如用“求职者”来代替“用户”会更准确些。 一种将角色融入故事的模板：我作为（角色），想要（功能），以此（商业价值） 只为一个用户编写 当故事只为单一用户编写时，故事的可读性是最强的。 以主动语态编写 要写成“求职者可以发布简历”，而不是“简历可以被求职者发布” 由客户编写 向故事卡编号说“不” 给故事卡编号会增加无谓的流程，并导致我们去抽象的讨论需要形象化的功能。 不要忘记意图 故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。既然仅仅是一个提醒，就要保持它的简洁性。加入必要的细节，以便联想到继续对话的切入点，但不要加入太多细节并以此取代对话。
估算用户故事 故事点 可以用户理想日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。 以团队估算 客户和产品经理可以参加，但他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。 估算 Wideband Delphi方法，与采用迭代方式进行开发软件的极限编程类似。 目的是要为故事得到一个统一的估算值。这个迭代过程很少超过3轮。 三角测量 帮助团队验证他们没有逐渐改变一个故事点含义的有效方法，不过可以不是特别精确。 使用故事点 我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必保证每次迭代的故事点的度量是一致的。 如果用结对编程呢？ 团队用不用结对编程，对故事点估算并没有影响。团队可以采用理想结对日或理想个人日来估算故事点，区别会表现在速率值上。 一些提醒 一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等。 类似地，一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。 开发人员职责 1.负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。 2.负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。 3.负责以团队估算。 4.负责估算应与其他估算一致。即所有2点的故事都应该差不多。 客户职责 负责参加估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。