[Day21] Scrum失败经验谈 – 没有价值的User story

User story：用一个简短的句子，描述用户的需求价值，也是大家所熟知的，身为一个「角色」，我想要「做某些事」，以至於我可以「有什麽价值」(As a [role], I want to [do something], so that I can [get value])，一个好的User story需要具备INVEST特性：

• 独立的(Independent)：每一则的User story要尽可能是独立的，意即和其他的故事相依性越低越好；
• 可协调的(Negotiable)：在安排进入开发期程之前，故事要具有弹性，可以调整，甚至可以重写；
• 有价值的(Valuable)：对使用者来讲，这故事的产出结果是要有价值的；
• 可预估的(Estimable)：User story的大小、难易，到所需费的时间，是要能被预估的；
• 够小的(Small-sized)：User story不能过大，不能大过一次开发周期。
• 可测试的(Testable)：User story或是相关的描述规格，要提供必要的资料，让故事是可以测试的。

当提到User story的时候，前述的资讯应该对你我不难，想要再深入找多一点，也脱离不了上面的内容，所以，User story很简单罗？不，User story是我失败的第二大事。「身为一个工作者，我想要一键领工的功能，以至於我可以一键自动领到我应完成的数量」这是我去年撰写的User story，现在来看看这个故事是否符合INVEST原则：故事很独立、好像可以被协调的、产出之後有解决一个问题，所以有价值、很明确可以预估、也很小、也能测试，嗯，符合INVEST原则，当初，在寻求Scrum指导时，我拿这个例子，也是获得这样的评价。User story依据其大小，由大到小可以区分成Theme、Epic、Story、Task，因为是形容价值，所以在撰写User story的时候，可能它涵盖的范围(Scope)很大，就会被视为Theme等级，然後逐步拆解成，Story或Task等级。去年我所撰写的User story，从Theme开始到Story，都是方才例子的样貌。大家有发现问题吗？User story的value全数建立在产出(Output)，以「有无」来断定价值，等於就是没有商业价值，工程团队无法理解使用者为什麽需要这样的功能，User story变成是spec，User story不该是spec，其应该要传达许多商业价值，像是痛点的被解决、效能的提升，而达到这些商业价值的做法，应该是多元的，变成Spec的User story，就像是向工程团队告知只能如此做。没有绝对的错，如果PO很明确掌握使用者、使用者很清楚问题是什麽、或是解法很单一明确，Spec化的User story不会有太大的问题，但绝对损失工程团队能贡献的最佳杠杆效益：不同的科技解方，并且让工程团队只是个工具人的团队而已。

我累积了不少没有价值的User story，所以即便再加上UI flow, flowchart等等规格元素，工程团队也照本宣科，产出了很多的成果，终究未能解决任何使用者问题。我现在写User story，十分在意把商业价值(Outcome)写清楚，定义好input和output需求，我并没有画出flowchart, UI flow，令人讶异的是，比起以前，需要将User story撰写的十分清楚如Spec，反而现在的结果，会超出我的想像，也受到使用者大大的赞赏，我会归功於当把价值说明清楚，可以帮助工程团队感受使用者的痛，工程团队也能以解决问题的角度，询问许多开放性问题，让他们可以提供更好的解决方案。把User story的价值说清楚，也可以让我们在有限时间下，trade off一个在条件下，最适合的解法，给予工程团队更多空间，成为一道活水，带动起解方与使用者需求间的流动。User story不是Spec，Spec是已经非常笃定output价值下的执行依据，所以不要将User story写成Spec，我们才能与工程团队一起合作解决问题！