User Story

2019/06/10 (增加連結)
2020/03/15 (將user story mapping內容獨立一頁)
2022/05/08 (內容微調)
2023/03/10 (內容調整)
2024/02/14 (補充內容)
2024/02/28 (補充MVP，內容調整)
2024/03/16 (Details for English references added)
2025/03/01 (新增投影片)

簡介

一般而言，user story是由使用者寫，所以，是以使用者的角度與語言來寫，而且是簡單的敘述，如:「我是個店員，我希望能看到還沒有出貨的消費者訂單，而且訂單最好是依照下單的先後排序，這樣子我才不會漏掉任何訂單」。以user story的方式分解，就是:

• 我是個(As a)店員

• 我希望(I want)能看到還沒有出貨的消費者訂單，而且訂單最好是依照下單的先後排序

• 這樣子(So that)我才不會漏掉任何訂單

從敏捷式開發的觀點來看，需求有兩個面向，一個是從使用者觀點來看，由使用者描述希望系統能做些什麼以便達到什麼目的，另一個則是從開發者的角度，分析並統整使用者的需求。可以使用User story來簡單的陳述使用者的觀點(詳參: 使用者故事)，再以流程圖(或活動圖)、雛形介面或測試案例來做為需求規格 (詳參: 敏捷開發需要哪些文件?)。

User Story必須排優先順序，一般而言，會採用Minimum Viable Product (MVP)原則，MVP原則可以說是「成功達到想要之成果的最小產品釋出」﹐如果不確定甚麼樣的產品會成功，也可以思考「能夠用來證實你的假設的最小產品釋出」 (詳參: MVP 應該是什麼?)

例如，一個完整的書店系統需要能夠

• 訂購書籍

• 處理訂單

• 管理存貨

• 產生銷售報表

• 推薦商品

可是店長不確定消費者是否能接受網路下訂單，所以，希望先有個簡單的成品，至少可以:

• 訂購書籍

  • 依類別尋找產品

  • 看產品詳細資訊

  • 管理購物車

  • 產生訂單

• 管理存貨

  • 出貨 (標記訂單已出貨)

如果，這樣的功能消費者可以接受，那就可以放心投入資源繼續開發。也可以根據使用者的實際使用經驗去規劃要加強哪些功能，或者哪些功能優先開發。

過去階段式開發，會分階段完成功能，但是，每個階段所完成的功能不一定能產生價值，例如，只完成註冊、登入，對使用者而言是沒有價值的，而MVP的概念是最小的可用產品，成品要能產生價值。

Card, Conversation, Confirmation

將使用者故事寫在User Story Card上，對話 (Conversation)才是使用者故事成功的關鍵，開發者要透過對話去了解使用者的需求，確認 (Confirmation)是利用接受條件(Acceptance Criteria)來確認這個使用者故事完成。(詳參: Essential XP: Card, Conversation, Confirmation)

User Story Card

通常使用者故事會寫在一張卡片上，或者，整理成表格，基本上會有這些欄位

• Story name

• As a (角色, who)

• I want (需求, what)

• So that (價值, why)

• Acceptance Criteria (可以參考Acceptance Criteria)

• comment

還可以加上

• user story的類別 (如:user activity, user task, user story) 

• user story的規模

• user story的優先順序

• 相關的user story

• 情境 (when, where)

• 如何完成 (how)

例如:

• 名稱: 依類別尋找產品

• 類別: User story

• 角色: 身為 購買者

• 需求: 我想要可以 依類別瀏覽產品資訊

• 價值: 因此我可以 從產品類別中找到我想要的產品

• 接受條件: 

  • 購買者可以看到所有類別中的產品 (產品名稱、價格)

    • 若超過十個產品每頁十個產品

• 優先順序: 1

詳參: 

• 編寫使用者故事

• 用戶故事（User Story）

• Agile Story Card Templates

• User Story Template

常見的問題

同學常見的問題

• Q: 如果不同使用者的User Story是一樣的，要寫兩次嗎?

  • A: 不同使用者的User Story應該會不一樣，如果一樣，可能是:

    • 沒把不同角色所需要的資訊想清楚，以為是同樣的User Story，店家跟消費者的查詢商品，表面上看起來一樣，但是，仔細去思考，會發現查詢目的及內容是不一樣的，店家關心的是商品銷售狀況、庫存狀況，而消費者則是想知道價格及功能。

    • 在這個User Story中不同的使用者的目的及功能需求是一樣的，所以，不需要區隔使用者。

• 把Epic (User Activity、User Task)當程式是畫面的區隔，同一個user story出現好幾次

  • user story不是畫面設計，是功能的盤點，同一個功能需求只會出現一次

• 當User story太複雜，應該切割為多個user story。或者user story太細，應該合併為一個user story。切割的原則是，要分為不同階段開發，就應該切割，分為兩階段開發後第一個階段的功能無法獨立產生價值，就應該合併。例如，可以把註冊及忘記密碼分為兩個user story，但不應該把登入，切割為輸入帳號、輸入密碼兩個user story。

• 不區分使用者，所有的I am都是「使用者」 (詳參: 撰寫使用者故事常見的問題 的第一項)

  • 區分使用者很重要，例如，一個二手商店會有買家跟賣家兩種角色，雖然，同一個人有時會是買家，有時會是賣家，混在一起常常就會忘了另一個身分的需求。所以，應該要把角色區分清楚。

• 不是從使用者的立場來寫，而是以開發者的立場在思考 (詳參: 撰寫使用者故事常見的問題 的第二項)

• I want跟so what弄反了，I want是具體的系統功能需求，so that是解決了使用者的什麼問題，或提供了什麼價值 (詳參: 撰寫使用者故事常見的問題 的第三項)，有些人建議，As A及So That由使用者來寫，開發者再依使用者的價值與使用者討論並決定具體的系統功能需求

  • 通常會重複寫，例如: I want 依分類看產品，so that可以依分類看產品，應該描述這功能對使用者的價值是甚麼，如: 找到我想要的產品以進行線上購買

• 接受/驗收條件

  • 沒有列出接受/驗收條件 (詳參: 撰寫使用者故事常見的問題 的第四項) 或太粗略

    • 需求必須在接受條件中說明所需要的資料 (如:產品名稱、價格)

      • 因為需求不清楚，常常是開發之後才發現移漏了重要的欄位

  • 接受/驗收條件並非描述系統需求

    • 有些人把接受條件寫成開發步驟:完成介面設計、完成資料庫設計....，這些通常稱為Definition of Done (DoD)

延伸閱讀

• User Story

  • 使用者故事 User story

  • User Stories (1) 什麼是 User Story?

  • 如何寫出 User Story

    • 首先，了解你的User、定義你的角色

    • 從角色出發，粗略但簡明的寫出 User Stories .... in Epic!

    • 拆解Epic，成為可執行的 Ready User Stories

    • 加入驗收標準 (acceptance Criteria)

    • 用有效率的工具或平台管理這些Story

  • User Stories by Mike Cohn (MountainGoatSoftware.com) **

    • What Is a User Story?

      • User Story Template: What It Is and Why It Works So Well

        • As a (role), I want (function) so that (business value).

      • Introduction to User Stories

    • What Is a Good User Story?

      • Card, Conversation, Confirmation

    • How to Write a User Story

    • Who Writes User Stories?

      • Anyone can write user stories.

    • When Are User Stories Written?

      • User stories are written throughout the agile project.

    • Can You Show Other User Story Examples?

    • How Is Detail Added to User Stories?

      • By splitting a user story into multiple, smaller user stories.

      • By adding conditions of satisfaction (acceptance criteria).

    • Do User Stories Replace Requirements Documents?

      • It’s often best to think of the written part as a pointer to the real requirement.

  • How to Write High-Quality User Story 

  • YOUR BEST AGILE USER STORY

    • Creating a User Story

    • Knowing If You Have a Story

    • Designing Better User Stories

    • Testing User Stories

    • Developing with Stories & Story Maps

    • Example A: Example User Stories from Enable Quiz (Startup)

    • Example B: Example User Stories from HVAC in a Hurry (IT Project)

    • Citations and Image Credits

  • 10 TIPS FOR WRITING GOOD USER STORIES

    • Users Come First

    • Use Personas to Discover the Right Stories

    • Create Stories Collaboratively

    • Keep your Stories Simple and Concise

    • Start with Epics

    • Refine the Stories until They are Ready

    • Add Acceptance Criteria

    • Use Paper Cards

    • Keep your Stories Visible and Accessible

    • Don’t Solely Rely on User Stories

  • 在 agile 中如何逐漸展開需求的內容

  • 撰寫使用者故事常見的問題

  • 撰寫 User Story 二三事 - 拆解和關聯性

  • How (and Why) to Write Great User Stories

    • User stories ≠ tasks

    • Stay high-level

    • Understand the users

    • Think as a user

    • Think big

    • Use epics

    • Don’t discard — prioritize instead

    • Setup for success — not just acceptance

    • Tag stories, add metadata

    • Don’t stick to sticky notes!

    • You still need specs

    • Visualization helps

  • Story Splitting Cheat Sheet

  • Agile LEGO City workshop: 用樂高積木來模擬敏捷開發的實際情形的一個小遊戲

• User Story與Use Case

  • Use Cases 和 User Story 不同之處

  • User Stories和Use cases的差別

  • Use case 和user story的差別(2)

  • Use Case和User story的差別 - 範例篇

• 常見問題

  • 撰寫使用者故事常見的問題

  • 7 reasons some user stories aren’t useful stories

  • 5 Common User Story Mistakes

  • 5 Classic Mistakes Made While Writing User Stories

  • 5 Common Mistakes We Make Writing User Stories

  • 3 Common User Story Mistakes

  • 7 Common User Story Mistakes and How to Avoid Them?