到底User Story是什麼？又該怎麼寫User Story？什麼情境下該寫什麼樣的User Story？
想必大家對於這些問題不管是產品經理還是產品設計師甚至是工程師對於「User Story」的認知多少不太一樣吧？但這個字眼卻常常出現在產品開發的過程中。因此在這裡分享我與「User Story」的愛恨情仇
使用者故事（User Story）的眉眉角角（上)
- 為什麼需要 User Story
- 什麼是 User Story
- 什麼時候使用 User Story▪︎ 為什麼需要User Story？
在開始使用user Story時，應該要知道到底User Story是什麼，以及為什麼要使用它？使用後可以為團隊帶來什麼樣的好處？
- 溝通，協助團隊達成共識
不同的角色對於產品功能的認知會有落差，慣用的語言也不盡相同。此時透過使用者故事來表達產品與功能的價值，可以更快的與團隊的所有人達成共識 - 計畫，釐清需求，排定優先級
透過使用者故事，釐清問題的需求。是否滿足用戶？是否符合公司的規劃？是否適用於現在的策略？並可以更快的釐清問題的次序與排定優先級 - 集中於開發，專注在特定目標
透過集中在定義好的使用者故事中，可以幫助團隊集中在特定的目標外，可以幫助開發團隊更具批判性和創造性的思考。 - 降低項目風險
以用戶需求出發，確保在產品開發的路上始終圍繞著用戶。且以用戶為中心的開發過程旨在最大限度地提高可用性，並滿足消費者。透過提高用戶的滿意度，降低反覆開發的風險。
▪︎ 什麼是User Story？
在維基百科裡面提到User Story 是「一段簡單的功能表述。以客戶或使用者的觀點撰寫下有價值的功能、引導、框架來與使用者進行互動，進而推動工作進程。」
User Story該具備的公式如下：
作為一個 「角色」，我想要「做某件事」，來得到「有價值的結果」。[ 角色 ] ：強調由「誰」去做
[ 動作 ] ：強調使用者「做了什麼」
[ 價值 ] ：強調做這件事對於角色的「價值」
Jessy可以檢視至少20個可以購買的舞蹈舞蹈課程，以便他可以在手機重新預定課程，無需請求櫃檯人員協助
Jessy可以在選出的課程內查看上課時間與上課地點，以便他可以更快速的決定是否要購買該課程。
Jessy可以查看選中的課程中挑選日期與上課時間，並在2秒內檢視是否可以購買，以便快速結帳，避免課程售罄。
好的user Story因為清楚的定義用戶並闡述內容及原因，並同時包含「有價值」、「獨立性」、「驗證性」、「可估計」四大要素。
- 有價值/Valuable：提出進行的工作可以提供給用戶什麼樣的價值
- 可獨立/Independable：故事間彼此的依賴過大，則會在開發階段互相牽制，造成開發時程的延宕。獨立性越高的故事，越能獨立交付。
- 可驗證/Checkable：所有的故事都必須要可以被驗證。
- 可估計/Estimable：設計師與工程師是否可以估計實際工作內容？
關於第三點可驗證，想了解更多如何撰寫「驗收條件」可以參考Vince Huang的這篇【文思不藏私】敏捷小班～驗收條件文章
▪︎ 什麼時候使用User Story？
那什麼時候可以使用使用者故事呢？Anne Hsiao的文章中有提到User Story常見的三種情景，我覺得這篇文章講的很好，因此就以Anne的分類來舉例說明：
- 中長期的優先排序 (需求釐清)
[ 溝通對象 ] 利益關係人(老闆/BD/CS)、產品團隊
[ 出現場合 ] 產品路線圖（Product Roadmap）、產品待辦清單（Product Backlog）
[ 細節程度 ] 方向大而模糊
[ 最終目標 ] 達成共識、確認優先級、是否符合公司策略通常，在與利益關係人釐清需求時，為了可以讓所有人都理解本次目標以及想達成的目的，通常會以用戶的角度出發，協助每個人理解並達成共識。但通常在這個階段，不需要將故事寫的很詳細。只需要一個模糊的大方向。在一些比較嚴謹的團隊可能會使用Epic、User Case來稱呼需求。
User Story
Jessy可以使用手機，在2分鐘內重新購買她取消的舞蹈課程，而無需尋求舞蹈教室的櫃檯人員協助處理。
2. 功能需求的發想與定義
[ 溝通對象 ] 設計師、產品團隊
[ 出現場合 ] 產品需求文件
[ 細節程度 ] 方向中等，但需要明確列出用戶的需求與內容
[ 最終目標 ] 確認需求、聚焦目的、選定方向一個問題或需求，可能有好幾種解決方式，透過使用者故事，來定義整個故事的走向後提出最適切的解決方案。
User Story
[解法一] Jessy可以在購買紀錄中，點擊重新下定後選擇上課的時間與地點。
[解法二] Jessy可以在首頁直接找到曾經預定過的課程紀錄，並快速購買流程。
[解法三]Jessy可以在篩選條件中找到想要的課程，且可以看到20個以上的課程。
….
3. Sprint Planning
[ 溝通對象 ] Scrum Team、QA、開發人員
[ 出現場合 ] 產品需求文件、Scrum/Kanban Board
[ 細節程度 ] 詳細，明確定義出範圍與動作行為
[ 最終目標 ] 規劃時程、協助團隊估時最後，就是透過story來安排與規劃時程，可以透過詳細的故事來制定驗收標準，與估時估點。有些嚴謹的團隊，會將一個User story切成好幾個task。透過將範圍縮小後，可以規劃在下個Sprint需要完成什麼事情。
User Story — 選擇解法一
購買紀錄中，可以看到過往的所有購買紀錄。紀錄依照日期排序離今天最近的牌最前面，這樣可以更快的找到上次的購買紀錄。
點擊購買紀錄，可以查看相同訂單是否可以重新下定。如果可以重新下定，則會出現重新下定按鈕。
點擊重新下定後，確認上課時間與上課定點，並告知價格。
…
結語
寫到這裡才發現，User Story真的是不同公司的用法與情境會不一樣。每個工程師與設計師習慣看與敘述的模式也會不同。其實在產品開發的過程中User Story只是工具的一種。目的是讓團隊可以更好的凝聚共識，並朝相同的方向前進。因此不要只顧著寫文件，在不確定的情況下可以找別人一起聊聊天。或許會有意想不到收穫喔！
下一篇，會繼續講關於User Story的分類以及大家所謂的Epic、User Case、Task 與User Story該如何分層與劃分。
👏 如果喜歡我的文章歡迎幫拍拍手，有想看哪方面的文章也歡迎底下留言👏如果對於文章有任何意見與反饋都歡迎一起留言與討論！
