【文思不藏私】敏捷小班～Scrum 使用者故事

使用者故事（User Story）是敏捷方法中用來描述需求的一個方式，而確認一個使用者故事是否『完成』（Done）則是需要『驗收條件』（Acceptance Criteria）來輔助。

使用者故事（User Story）

在敏捷方法中常用的『使用者故事』（User Story），包含了幾個元素

• 使用這個服務的人，稱之為『角色』（Role），使用的語句為『身為一位⋯⋯』（As a ⋯⋯）。這一部分描述的重點是『誰』（Who）。
• 這個人要用這個服務完成什麼事，稱之為『描述』（Description）或『行動』（Action），使用的語句為『我想要⋯⋯』（I want to ⋯⋯）。這一部分描述的重點是『做什麼事』（What）。
• 為什麼這個使用者需要這個服務，稱之為『目標』（Goal）或『商業價值』（Business Value），使用的語句為『因此我可以得到⋯⋯』（So that ⋯⋯）。這一部分描述的重點是『為什麼做』（Why）。

好故事的條件

一個好的故事具備了幾個條件，分別是 V.I.N.C.E。

• 有價值（Valuable）：故事最重要的一個部分是故事描述的『商業價值』，可以很清楚地讓團隊知道正在進行的工作是對『用戶』是有價值的，了解為何而戰，才能更有動力。
• 可獨立（Independable）：所謂的『可獨立』是指使用者故事和使用者故事間應該儘量避免相互依賴。傳統需求描述方式由於描述的事件較大，彼此間的依賴過多，導致在開發階段時互相牽制，造成開發時程的延宕。獨立性較高的使用者故事比較容易能夠獨立交付。
• 可協調（Negotiable）：使用者故事的「可協調」是指團隊對這個使用者故事的理解是透過不斷的對話、協商後慢慢達成一致的共識，進而開始開發階段，而不是產品負責人說了算的。曾經在奧美廣告的會議室看到了『對話、對話、不斷對話；優化、優化、不斷優化』，這句話的深層涵義是『持續的對話才能讓產品持續的優化』。
• 可驗證（Checkable）：所有的需求都是需要可以被驗證的，因此一個使用者故事，不只是故事的句子，還需要有相關的驗收條件可以驗證核對。
• 可估計（Estimable）：如果一個需求是不可被估計的，一則表示這個使用者故事太大，一則表示這個使用者故事太過模糊。太大的故事需要被切小，簡單來說就是分階段完成，太模糊的故事需要時間釐清需求。

【iT邦幫忙30天鐵人賽】敏捷 30 天養成計劃

【請用你的掌聲來投票與支持】
感謝你認真的讀完這篇文章，你的支持會是我持續寫作的動力
如果你還喜歡這篇文章請給我 1~4 個『掌聲』
如果這篇文章對你有幫助請給我 5 個以上『掌聲』【文思不藏私 Facebook 粉絲專頁】
如果你對我這一系列文章有興趣歡迎『Follow』我或『分享』給你的朋友
也歡迎你將你的看法『回覆』給我【誰是文思？】