當你進入敏捷流程，接下來的課題就是構思產品或服務的樣貌、產品該具備何種功能。不過，如果把產品需求設定太大，會沒辦法在一個衝刺階段開發完畢，就失去敏捷的原意。發明敏捷的傑夫-薩瑟蘭 (Jeff Sutherland) 進一步分析，部門之間在商討中內容時，最好出現的溝通障礙是，每個人對於需求和完整度的 ”理解” 不太一樣。

舉例來說，你是大賣場的員工，老闆準備關閉小店舖，多開大型店面，要你查出在北部地區、店面面積超過600坪的銷售狀況，不過，老闆並未把這個需求 “背後的意義” 完整表達，讓你覺得又多了一件事情要做，導致錯估形勢。

明確指出，“為什麼要做” 寫出好的使用者故事
當你在擬定需求時，如果只是列出任務名稱，其他人會不明白 “為何要做這件事”。為了解決這個困擾，可以撰寫 “使用者故事” (user story) 來說明任務重點。

基本架構: 做為一個使用者 (user)，我想要做一件事 (activity)，以達到有價值的目的(value)。

撰寫秘訣: 要把故事深入淺出，盡量用1~2句話就能說明清楚事情，以下以網路書店為例。

壞的使用者故事：

我們要開一間網路書店，讓讀者找到想看的書	身為網路購物者，我想要快速下訂單	身為部門經理，我希望了解每個人喜歡看什麼書
對象範圍太大	缺少要做的事	未列出價值目的

好的使用者故事：

在撰寫使用者故事的時候，就應該融入關鍵客戶的需求。薩瑟蘭表示，人在思考時，如果有情節、故事輔助，更能釐清內容，較能掌握需求的全貌。因此，各部門在討論專案時，建議使用者故事(user story)的方式列出需求，加強溝通。撰寫一個故事，需包含 “為誰而做？(who)” 、 “要做什麼(what)？” 、 ”為什麼要做這件事(why)？” 等三大面向，呈現出來的典型句子，則是 “作為一個使用者，我想要某種功能，以至於達成某個目的。”

使用者故事能夠明確闡述人物、慾望、動機的內容，可以讓每個人對產品的最終呈現有一致想法。例如，有個故事的情節是 “我想要一輛車，用開車上班” ，如果敘述的人分別為 “我是住在首都的通勤族”、 “我是鄉下的農夫”，這兩個故事中，所需要的車款可能就不太相同。更重要的是，使用者故事也不能太大，盡量要由明確的短句組成，否則就沒辦法在一個衝刺期間完成。倘若定義過為廣泛，就得把它拆成更小的故事來說明。

使用者故事的6要素：

薩瑟蘭指出，判斷使用者故事是否完整且確實表達需求，可以採用 “ＩＮＶＥＳＴ標準” 檢視：

1. 獨立性 (Independent)

故事本身能定義一件事，不會和其他事件相關。

2. 可協商性 (Negotiable)

只要任務還沒有做完，都可以重新撰寫，修改。

3. 有價值 (Valuable)

故事要替客戶使用者或利害關係人創造價值。

4. 可估算 (Estimable)

要評估團隊，有沒有能力跟知識做這些事。

5. 規模小 (Small)

故事要盡量短小，至少要在一個衝刺會議完成。

6. 可測試 (Testable)

故事要能夠被測試，確認最後能完成它。