用户故事拆分案例分享——SPIDR实践

本周在一个团队的回顾会中，注意到一个有启发性的小抱怨。团队在最近的迭代中实现了一个复杂的用户故事，但最终产品所有者（PO）认为需求没有得到很好的实现。这引发了对为何复杂的用户故事会被安排在当前迭代中的思考。

在回顾会上，团队认为故事的复杂性超出了他们在迭代时间框架内能够应对的范围，因此没有完成得很好。我提出了两个问题来探讨问题所在：

1. 这个用户故事的核心诉求是什么？
2. 若只实现核心诉求，相当于目前工作量的多少？

团队对第一个问题的回答不清晰，这可能是评估不准确的原因。经过与PO和需求了解人员再次确认，明确了客户的核心需求是希望将核心数据存储在自己的存储介质上，以满足安全合规要求。

为了拆分这个需求，可以根据我之前文章中提到的“五种简单高效的拆分用户故事方法”，考虑到两类用户场景：

• 全新的注册用户。
• 已有用户希望使用BYOS（Bring Your Own Storage）功能。

我们可以按照这两种场景拆分用户故事，让每个故事都满足INVEST和MVP原则，同时能够快速投入市场并满足部分用户需求。当询问团队如果只为新注册用户实现BYOS会怎样时，他们回答工作量将只有20%。

这样的拆分可能属于SPIDR法则中的Paths或Rules。这种拆分方式保证了需求的完整性和对客户的价值。

Bruce有话说：我们往往过于关注功能的实现，而忽略了用户真正有价值的需求。合理地拆分用户故事，让迭代能够体现用户期望的价值，才是我们应追求的效果。横向功能拆分和纵向业务需求拆分是突破传统思维的关键。Mike Cohn的SPIDR拆分法是一个不错的开始，值得我们练习和应用。