大多数人写用户故事的时机都是错的

1. 找到需求的始作俑者，就是写需求文档的那个人；

2. 请他从现在开始停止写需求文档，否则你还是逃脱不了需求文档转用户故事的命运；

3. 请他把要做的事情一股脑全放到Product Backlog中；

• 一定要以用户的视角来写；

• 一件事情一条；

• 不管是短期要做的，还是很久以后要做的，都要放进去；

• 只写一句话标题，不填写详细内容。

    把所有要做的东西都放到Product Backlog中的好处是：

• 可以清空大脑，每天开心清爽；

• 需求池作为需求的唯一来源，防止疏漏。

• Product Backlog中的故事会随着时间推移增加甚至是删除（如果发现确实不需要了）；

• Product Backlog中故事的相对优先级会动态调整。

#1 千万不要在遥远的故事上花费大量的时间，切记切记！一句话标题用来占位足够，再不成可以加上怕自己忘记的几个要点。因为未来的事儿谁也说不好，也许过一段时间想法就变了，或者无限期搁置，甚至有可能不需要了，过早做就是浪费！

#2 在Product Backlog顶端的高优先级故事，如果拆的更小，也许你会发现，拆出来的故事可能只有一部分会保持原来的优先级，其余的也许可以调到更低的优先级，为其他更高优先级的故事让路。

传统的需求和敏捷的用户故事，真的有可能在写完的时候长的差不多。我认为根本的区别是它们形成的过程和书写的时机。

用户的视角、细致的拆分、渐进明细、优先级动态调整、减少浪费、快速响应等等优势的综合体，让用户故事在敏捷世界里更具竞争力！

推荐阅读