产品研发都从需求开始，Scrum中称为用户故事(User Story), 并且对于US描述有固定的格式。那么新的Scrum master可能会问到，我们之前没有用户故事，但有MRD，市场需求，需求文档等等诸如此类的话，而且数量还不少，怎么办？从头再来吗？
从现实情况来讲，Product owner或者产品经理，能用用户故事形式把需求讲清楚的比例非常少，或者需要经过大量的训练才可以具备这样的能力，所以建议是将现有的文档进行细化和切割，差不多可以按2~4周这样的工作量，具体参考团队内部定义的sprint时间, 经常会听到有人说，我负责的部分不可能细分到2~4周，导致这样的情况出现，通常是因为需求粒度过大或者是开发者缺少相关经验。解决的办法其实也并不复杂，团队在一起多问几个为什么？这个可以参考质量工具中的8D报告，通过刨根问底的办法，让隐蔽的需求彻底暴露出来。
对于US大小的评估，可以使用推荐的卡牌游戏进行团队全体评估，也可以类比规模和复杂度相似的已有项目。因为Scrum的特点就是短周期迭代，所以开发时间中包含大量水份的情况会被减少，但并不是说每个sprint中不需要预留一些buffer，因为很现实的问题，就是团队整体能力有一个逐步提升的过程，另外释放前的回归测试出现缺陷，也需要预留一定的时间进行缺陷修复和多轮回归。
故事写得好不好，Scrum提供了一套评估的原则(INVEST)
Invest描述:
I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。
N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。
V aluable(有价值的):每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
S mall(短小):一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。
T estable(可测试的) :一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。
留一个问题，如何给百度首页写用户故事？
