本系列已出版《Agile一本通！敏捷新手入門導引》，增加了更棒更豐富的內容，歡迎到博客來參觀選購~
這本超讚>> https://www.books.com.tw/products/0010968755

經過上一階段團隊成員的集思廣益，灰貓在一旁列出了一疊小紙條。為了方便分類與整理，灰貓首先在白板上寫上 活動、步驟、細節、未來release， 畫線區隔開來。

接著將紙條分類，依照活動重新排列在白板上

「貨車動態很重要，為什麼要之後才上？」

「菜箱送錯更糟糕吧?」

成員們你一言我一語，每個人都覺得自己的功能很重要。這時候灰貓說:我們先回到廚房阿姨的需求吧

身為[廚房阿姨],我希望[訂菜系統可以在司機快到前通知小幫手]，這樣[司機就不用等這麼久了]

「阿姨主要希望貨車快到之前，系統可以簡訊通知小幫手。」

「你們說的功能確實重要，但我們可以先做阿姨要的功能，看看阿姨的回饋，再決定下一個Sprint要做什麼。」

「第一個Sprint，就先完成貨車到達前的部分吧!」

user story mapping的使用情境

以往使用瀑布式開發時，由使用者提出需求，有些使用者會準備畫面或想要功能的類似產品，請開發團隊幫忙開發。

然而經常發生:

1. 使用者想要的很多，導致產品最終變得肥大，卻只有當中的部分功能經常被使用，也只需要這些功能就能滿足使用者的需求
2. 使用者提出的想法無法解決實際面對的問題或滿足需求，導致投入大量時間開發上線之後，才發現產品乏人問津，後續才提出其他解法，小則修改部分功能/介面，大則需要整體重構

使用user story將使用者核心的問題/需求定義出來後，由開發團隊集思廣義思考解法，先完成最核心的功能，再由每一次release進行修正，如此可避免投入大量人力與時間開發後的產品不符合期待。

容易歪掉的部分

1. 越討論越發散，認為每一個功能都很重要，無法取捨，導致無法於一個Sprint完成

2. 團隊成員本身有執行scrum的精神跟共識，但外部合作團隊/使用者/長官並不理解，導致待辦太多、不可能在一個Sprint中有品質的完成

3. 使用者/長官無法尊重開發團隊提出的解法或建議，執意照自己的想法做事，即使團隊已提醒該作法/功能，並不能解決問題

今天的參考資料/延伸閱讀:
User Story Mapping 101