（一）
Epic 或者 Feature 才是最终可交付的东西。而 Story 很多时候则是不可单独发布的，所以很多 PO 或者团队会有这样的疑问，为什么还要把 Featrue 拆成尽可能小的 Story？
1. 加快反馈。小的 Story 经过开发、QA、Demo的循环，可能会产生新的 Learning。
2. 识别优先级。拆小之后，会发现有些点不是必做的。
（二）
Story 一开始叫 User Story，其余的很难归于用户故事的，可以称之为 Technical Spike。
现实中则有很多演化。
1. 比如一个后端API，给小程序、安卓、iOS用。理想的情况是这些团队属于一个Scrum Team，Story 是端对端的。然而不理想的情况，App端和后端属于不同团队，也得找条活路。这时候可以把后端 API 作为单独的 Story。
2. 再比如 Feature 拆成多个 Story 后，每个 Story 都单独验收过了，可是对 Fearure 的联合测试怎么办？可以有个 Test Story。但注意它不属于任何单个 Story，否则的话应该归于那个 Story 的 Task。
3. 再比如，一个 Feature 做完需要发布时，发布需要额外的工作比如 ：生产环境的数据迁移。它也没法归于某个 Story。这种情况可以建一个 Release Story。
（三）
问题来了，这些形形色色的 Technical 的 Story，跟 Story 下面的 Task 有什么区别？
可以用 INVEST 的 Valuable 来区分：
Story 的Valuable 本来指的是对用户有价值，这边可以把用户的外延扩大，用户指的是“团队以外的人”。所以看上面的 Technical Story：
1. Technical Spike 的价值是对团队外的人澄清，某个 Story 能不能做，多大的 cost 和 Risk。
2. 后端 API 的价值显而易见是对前端团队。
3. 集成测试的价值是确保用户的外部质量。
4. Release Story 的价值也显而易见，让用户用上我们的功能。
所以，区别是，Story 对团队外的人有价值，或者对他们产生直接影响，属于 What。而归属于 S投入下面的 Task ，则只对自己或者本团队有价值，属于 How。
网友评论