本文1270字，阅读约需4分钟。用户故事对于每个敏捷小伙伴来说，似乎是再熟悉不过的东西了。然而，虽然我们对用户故事的写法如数家珍，但大多数人写用户故事的时机却是不对的。
What? 时机？不对？别着急，听我慢慢道来！你是否对以下的反模式非常熟悉呢？
反模式#1 将需求文档转成故事
这种情况最常发生在团队刚刚做敏捷转型时。那个时候已经有需求文档存在了，我们总不能立刻把需求文档扔到垃圾桶，从零开始写用户故事吧，所以大多数人干的事情就是用需求文档中的信息填充用户故事。从表面上看，写用户故事的工作就是把需求文档换一个格式。特别是在大公司，业务方和研发团队又不在一个团队，甚至不在一个部门。在研发团队把需求文档转成一堆用户故事的同时，业务方还在同时继续写需求文档。就这样，周而复始，没完没了，真的是转不完的用户故事啊！如此一来，团队就困惑了。先写需求文档，再转用户故事，敏捷是不是吃饱了撑的，直接按需求文档写代码不就完了吗，何必“脱了裤子放屁”呢？
反模式#2 只在迭代开始前写故事
马上就要开始下个迭代了，Product Backlog里还没有东西呢，怎么办？那就写啊！一顿狂赶，终于写完了，足足一个迭代的，还奔儿详细，老有面子了！这样做有问题吗？为啥是反模式？看完后面你自然就明白了！
反模式#3 所有故事都太详细
有人说了，不管Product Backlog里的故事是打算什么时候做的，只要放进去，就一定要详细，工作嘛，一定要像样！不成熟的想法放进去是会惹祸的，也显得草率啊！这样做真的可取吗？
推荐模式
终于到正题了！下面我来聊聊推荐的用户故事书写模式。
1. 找到需求的始作俑者，就是写需求文档的那个人；
2. 请他从现在开始停止写需求文档，否则你还是逃脱不了需求文档转用户故事的命运；
3. 请他把要做的事情一股脑全放到Product Backlog中；
一定要以用户的视角来写；
一件事情一条；
不管是短期要做的，还是很久以后要做的，都要放进去；
只写一句话标题，不填写详细内容。
把所有要做的东西都放到Product Backlog中的好处是：
可以清空大脑，每天开心清爽；
需求池作为需求的唯一来源，防止疏漏。
4.请他为Product Backlog中的故事排优先级，优先级高的放上面，优先级低的放下面。
5.看看Product Backlog顶端大概1-2个迭代的量，故事描述得够不够详细，有没有把事情说清楚，拆分的够不够细，能不能放入一个迭代（通常建议用户故事最好能在迭代长度的一半时间内完成）。如果没有，那么就想尽各种办法去搞定，包括和利益相关人沟通，当然也包括研发人员。
以上步骤#3-步骤#5要高频定期或不定期进行循环（这就是传说中Product Backlog Refinement的内容了），这时你就会发现
Product Backlog中的故事会随着时间推移增加甚至是删除（如果发现确实不需要了）；
Product Backlog中故事的相对优先级会动态调整。
这样我们就能够始终在做当前最高优先级的事情，而不是当初设定的优先级，因为环境在变，我们的优先级也要随着变！敏捷性由此体现！
注意事项
#1 千万不要在遥远的故事上花费大量的时间，切记切记！一句话标题用来占位足够，再不成可以加上怕自己忘记的几个要点。因为未来的事儿谁也说不好，也许过一段时间想法就变了，或者无限期搁置，甚至有可能不需要了，过早做就是
