大小"合适"的User Story

大小合适的 User Story

我遇到过很多团队的User Story都，动辄要两到三周才能完成。 而且信誓旦旦的说已经不能再分解下去了。但是根据我的经验，排除个别特殊情况的，大部分还是能够继续分解的。

我正在策划一个User Story拆解的系列文章，有些是我自己的经验，有些是翻译的国外大师的文章。但是在发布这系列文章之前，我想先聊聊什么叫大小"合适"的User Story。

我个人是主张User Story分解的越小越好的，原因主要有以下这些：

User Story分解的时候，隐藏在大块任务中的复杂度，困难，和风险就浮现出来了，这时你也会审视自己原来的计划，是否能够cover这些情况，是否需要添加额外的action来应对复杂性和风险。

在开始工作之后， User Story太大的话，更容易被工作中的琐事打断，无法一次性专注完成。工作被打断后重新回来，还要花时间捋清楚上次做到哪儿了，思路也要重新回顾。而小的User Story由于可以在短时间内快速完成，被打断的机会大大降低。即使被打断了，由于Story小，逻辑相对清晰，思路简单，也容易快速捡起来。

一个User Story由于意料之外的情况(未预见的风险，障碍等)发生，不得不中止下来，直到意外解决才能继续，是一件让人很沮丧的事情。大块Story遇到这种情况的机率更大。

现实中，由于某个Story暂停了，员工往往会在等待的过程里开始一个新Story， 原Story问题解决可以继续了，新Story可能并没完成，徒增了很多压力和协调的工作。 而Story分解到合适的粒度，就能降低这种问题的发生可能性。

那么问题来了，什么叫合适的Story粒度？

这是个没有标准答案的问题，具体的任务内容，与其他任务的关联性大小，甚至团队成员对业务和代码的熟悉程度都会对“合适”的范围造成影响。

然而还是有些现象可以帮助我们诊断User Story大小是否合适：

1: 如果你做Story的时候经常被其他事情打断，你可能需要更小的Story粒度帮你专注完成。

2:如果完成任务的过程中经常出现原来没有预见到的情况， 团队中有声音认为是由于对系统了解不够，或者对业务了解不够，但是短时间内又无法提升这些经验。那么Story分解的时候颗粒度再小一点，就可以立杆见影地解决部分问题。

3:如果你无法用三言两语描述你当前的Story的具体实施，并且让别人都听的清楚明白的话，你的Story粒度还需要分解的更小。

4:让大多数story的颗粒度保持在1-2天就能完成。或者一天能完成一两个。

使Story保持这样的粒度会让你每天工作结束时都会获得一点成就感。 而巨大的任务一直努力加班也做不完容易积累沮丧和压力。

我个人是使用Scrum Board来管理自己日常工作的。每天完成几个任务后，在board里将它们从In progress移到Done里，会带来满满的成就感。并且很积极的开始计划接下来要做的任务。 有段时间有一个大的任务几天没完成，我变的不愿意去看Board，也没有心情将新增的任务添加到Board的Plan栏里去，持续工作，没有获得『完成』的成就感也让我压力倍增，对手头的大任务厌恶起来。

我们知道什么是合适的User Story粒度了，那么下一个难题是如何将Story拆分到合适的粒度。Story无法继续向下拆分，最难拒绝的借口就是"关联性"问题，接下来我的User Story拆解的系列主题，就会针对这个问题进行探讨。欢迎持续关注本公众号。

公众号：生也有涯知也无涯

Wei Xin ID：lisa_summerwind

长按二维码获取更多敏捷&领导力技巧