用户故事信息过多或过少带来的问题

前言

[上一篇]文章介绍了用户故事拆分的 5 种方法，拆分故事需要足够的信息才能让 PO 或者团队来进行合理的拆分。所以 Mike 大叔给 PO 的意见是：“写用户故事就是在正确的时间给团队刚刚好的细节就够了”。而在实际中每一个用户故事所带的信息多少是参差不齐的，过少肯定不好，而过多也会带来一些问题。在本文，就让我们跟着 Mike 大叔的讲解探讨一下用户故事信息过多或过少带来的种种问题吧。本文是结合 Mike 的视频的个人总结，想看原版视频 Mike 大叔的讲解，请看下面连接的第三个视频:原文链接.

信息不够带来的影响  

PO 提供的用户故事的信息对团队来说不够充分，那么可能带来如下几个问题：

1. 迭代中团队会再次要求 PO 澄清需求，PO 去和干系人确认的过程可能会延迟若干天，这会影响迭代的进展。

2. 就算 #1 的确认及时返回，可能也会因为需求明确后导致用户故事的体积变大，无法在当前迭代完成。

Tips：用好需求梳理会(Refinement meeting)，在当次迭代前将涉及的用户故事需求和团队梳理清楚，避免在当次迭代内进行用户故事的需求澄清。

信息过多带来的影响  

对于团队来说，PO 提供的用户故事信息过多也不一定是好事，例如下面的情况：

1. 每一个用户故事可能包含很多验收标准(AC)，包括页面交互都已经提供给团队。

2. 甚至一些团队要求 PO，不能有任何一点未确认清楚的用户故事进入迭代。  

上面的情况会导致团队花很多时间来等待分析需求；同时由于信息足够完备，团队很容易成为"Code Monkey"——只是编码工具而没有了自己的思考；另外由于 AC 的细致和数量众多，可能会导致用户故事无法在一次迭代内完成，很多时候仍然需要多个迭代才能完成这个用户故事，从而无法成为一个真正敏捷的团队。

敏捷开发团队需要的不是事无巨细的事前分析，而是刚刚够的，之后通过实现可以从客户那里获得反馈，再进行调整。这样团队对用户故事的理解才会呈涌现状态，将实现和客户价值紧密联结起来。

总结  

作为 ScrumMaster，可以经常在回顾会上询问团队，对他们来说完成迭代内的任务，相关用户故事的信息是否足够清楚？

对于团队来说，他们想要有勇气来完成迭代内的用户故事，那么就需要用户故事能够做到：Just Enough & Just In Time。我们既需要及时的给予团队信息来分析和设计功能，也要给他们足够空间来思考需求，避免他们成为一个机械的"code monkey"。

【欢迎关注我的博客】