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

来自Mike Cohn大师的建议

Posted by Bruce Wong on September 27, 2020

前言

上一篇文章介绍了用户故事拆分的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,可以经常在回顾会上询问团队,对他们来说完成迭代内的任务,相关用户故事的信息是否足够清楚? askteamJIT
对于团队来说,他们想要有勇气来完成迭代内的用户故事,那么就需要用户故事能够做到:Just Enough & Just In Time。我们既需要及时的给予团队信息来分析和设计功能,也要给他们足够空间来思考需求,避免他们成为一个机械的”code monkey”。