前言
上一篇文章介绍了用户故事拆分的5种方法，拆分故事需要足够的信息才能让PO或者团队来进行合理的拆分。所以Mike大叔给PO的意见是：“写用户故事就是在正确的时间给团队刚刚好的细节就够了”。而在实际中每一个用户故事所带的信息多少是参差不齐的，过少肯定不好，而过多也会带来一些问题。在本文，就让我们跟着Mike大叔的讲解探讨一下用户故事信息过多或过少带来的种种问题吧。本文是结合Mike的视频的个人总结，想看原版视频Mike大叔的讲解，请看下面连接的第三个视频。原文链接
信息不够带来的影响
PO提供的用户故事的信息对团队来说不够充分，那么可能带来如下几个问题：
- 迭代中团队会再次要求PO澄清需求，PO去和干系人确认的过程可能会延迟若干天，这会影响迭代的进展。
- 就算#1的确认及时返回，可能也会因为需求明确后导致用户故事的体积变大，无法在当前迭代完成。
Tips：用好需求梳理会(Refinement meeting)，在当次迭代前将涉及的用户故事需求和团队梳理清楚，避免在当次迭代内进行用户故事的需求澄清。
信息过多带来的影响
对于团队来说，PO提供的用户故事信息过多也不一定是好事，例如下面的情况：
- 每一个用户故事可能包含很多验收标准(AC)，包括页面交互都已经提供给团队。
- 甚至一些团队要求PO，不能有任何一点未确认清楚的用户故事进入迭代。
上面的情况会导致团队花很多时间来等待分析需求；同时由于信息足够完备，团队很容易成为"Code Monkey"——只是编码工具而没有了自己的思考；另外由于AC的细致和数量众多，可能会导致用户故事无法在一次迭代内完成，很多时候仍然需要多个迭代才能完成这个用户故事，从而无法成为一个真正敏捷的团队。
敏捷开发团队需要的不是事无巨细的事前分析，而是刚刚够的，之后通过实现可以从客户那里获得反馈，再进行调整。这样团队对用户故事的理解才会呈涌现状态，将实现和客户价值紧密联结起来。
总结
作为ScrumMaster，可以经常在回顾会上询问团队，对他们来说完成迭代内的任务，相关用户故事的信息是否足够清楚？
对于团队来说，他们想要有勇气来完成迭代内的用户故事，那么就需要用户故事能够做到：Just Enough & Just In Time。我们既需要及时的给予团队信息来分析和设计功能，也要给他们足够空间来思考需求，避免他们成为一个机械的"code monkey"。
