一次用户故事拆分实战的感想

Power Question带来的改变

Posted by Bruce Wong on March 20, 2021

用户故事拆分的好坏经常是Team能否很好达成迭代目标的一个重要因素。将Sprint Backlog合理的拆分,可以让迭代内任务估算更容易,同时降低了任务间的依赖,让Team的效率也会更高,本周和Team进行了一次用户故事拆分,今天就分享一下这期间的一个有意思的感受。
团队正在讨论拆分的是一个预计3天能完成的中型用户故事。初始拆分是3个子任务,每个任务之间会有先后顺序依赖,也就是必须按顺序完成。大致任务内容如下:

  1. 后台数据库的处理逻辑。
  2. 对应数据库上层的应用层逻辑修改。
  3. 前台交互的对应变化。

这样拆分的每一个任务需要一天的工作量。最后QA需要在3天后开始测试。 于是我提了一个问题“如果只有1天而不是3天交付这个功能,并需要保证该用户故事最小MVP,你们如何实现这个功能?” 参与任务的几个小伙伴经过简单的思考,马上给出了另一种拆分方案,这次去掉了之前方案里面多余的假设和一些非必要的装饰功能,最后居然真的评估可以在1天内完成这个用户故事。

Bruce有话说

当团队拆分用户故事的时候,往往因为希望完美而增加一些假设和非必要的装饰功能。这时候可以通过今天分享的方式来引导团队转变思考方式,重新审视一下拆分方案的必要性。另外,强力问题是一个有用的手段,通过问题引发团队的思考,跳出当前的思维惯性。 对于用户故事拆分的方法,之前翻译过敏捷大师Mike Cohn的一篇用户故事简单拆分法——5种用户故事拆分法,感兴趣的小伙伴可以看一下。另外还有一个比较全的用户故事拆分图谱,有兴趣的小伙伴可以了解一下。
故事拆分地图

参考链接