用戶故事中的霸主

April 25 13:10~14:17

▲照片翻拍自《User Story Mapping》

 

採取用戶故事（user story）的團隊經常遭遇一個棘手的問題：「如何切出大小適中的用戶故事？」在〈需求的大小〉介紹過Investment Theme（投資主題）、Epic（史詩）、Feature（特性）、User Story（用戶故事）這種切割方法，今天要介紹《User Story Mapping》這本書的觀點。

《User Story Mapping》從三個角度來看用戶故事，由大而小分別是：

• 商業（Business）：從企業的角度來看，可以幫助企業達到某些商業上的成果。
• 用戶與客戶：滿足用戶或是顧客的需要。
• 開發團隊：開發團隊能夠在幾天內做完。

舉個例子，有不少敏捷開發團隊都有這種經驗，stakeholder（例如行銷或業務主管）在sprint review的時候一直批評團隊所完成的用戶故事「太小」，功能「太少」。聽到這種打槍式的「回饋意見」，團隊也覺得很無奈：「才兩個禮拜你是希望我們能做出多偉大的東西出來？敏捷開發本來就是迭代與增量開發，你要的這些功能不是我們不做，是安排在之後的sprint才會做。」

因為行銷或業務主管腦想看到的是「商業層面有價值的用戶故事」，但是團隊此次所展示的只是「這個sprit所完成的用戶故事」，兩者的範圍相差太大，所以產生認知上的落差。

***

「《User Story Mapping》認為，不管是叫epic或是feature，它們都是一種user story。所以當stakeholder或是Product Owner提出一個想法，團隊不要用「這是一個epic喔，你還沒想清楚，請把它切成user story再來討論」這種態度打發對方。而是應該透過雙方對話，一起合作切割成開發團隊所能夠施工的user story，這才是一種健康的協作模式。

▲照片翻拍自《User Story Mapping》

 

用戶故事中的霸主，還是用戶故事。

***

友藏內心獨白：大小不是問題，有沒有對話才是重點。