iT邦幫忙

2021 iThome 鐵人賽

DAY 21
0
IT管理

文化沒這麼理所當然:一位新手產品經理促成IT文化形塑的心路歷程系列 第 21

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


上一篇
[Day20] Scrum失敗經驗談 – 只想得太大太遠
下一篇
[Day22] Scrum失敗經驗談 – 承認就是隕石吧!
系列文
文化沒這麼理所當然:一位新手產品經理促成IT文化形塑的心路歷程33

尚未有邦友留言

立即登入留言