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，我們才能與工程團隊一起合作解決問題！