---
name: user-stories
description: 把功能構想或 PRD 的段落，拆成「身為／我想要／以便」格式的使用者故事，每則都附上用 Given/When/Then 情境寫的驗收標準、邊界情況和範圍外說明，最後再用 INVEST 檢查每一則故事。適用於有人要使用者故事、票券、驗收標準、待辦清單拆解，或要為 Jira、Linear 或 sprint「把這個功能拆成故事」的時候。
---

# 附驗收標準的使用者故事

好的故事寫出誰得到什麼、為什麼，而它的驗收標準說清楚團隊怎麼知道它完成了。「以便」那一句不是裝飾：如果你寫不出來，這則故事可能不值得做。每則故事都要小到一個 sprint 內做得完，而且不必問撰寫者就能測試。

## 適用情境

- PRD 或功能說明已經定案，工作需要放進待辦清單時。
- 已經有票券，但沒有人說得出怎樣才算完成時。
- 大型功能在估算前必須先拆開時。
- 不適用於決定要不要做這個功能：先用 prd-from-notes 或 feature-prioritization。

## 需要準備

- 功能說明、PRD 段落或筆記。
- 涉及的使用者類型（客戶、管理員、訪客）。如果沒有，問一次；之後就用「使用者」，並標上「[假設：角色]」。
- 已知的規則和限制（權限、方案上限、格式）。沒有提供的一律列為待釐清問題，不要自己編規則。

## 步驟

1. **列出角色和他們的目標。** 每個角色寫出他想用這個功能完成什麼。一則故事只有一個角色；「使用者和管理員」的故事是 2 則故事。
2. **每則故事都寫成「身為／我想要／以便」。** Dan North 說明這個範本會迫使撰寫者寫出價值。「以便」要寫使用者在意的成果，而不是把功能再說一次。如果誠實的「以便」只能寫「因為我們說要做」，就把這則故事標為建議縮減範圍。
3. **依使用者看得到的切片拆分。** 依工作流程的步驟、業務規則的不同情況、資料類型來拆，或先做順利路徑、之後再做例外。絕不依技術層拆分（「後端故事」、「前端故事」）：每則故事都必須交付使用者可以實際試用的東西。
4. **用 Given/When/Then 寫驗收標準。** 假設（Given）= 起始狀態。當（When）= 唯一的動作。那麼（Then）= 可以觀察到的結果。額外的條件用「而且」（And）接上。每則故事寫 2 到 5 個情境（本技能的預設）：順利路徑、至少 1 個失敗路徑，以及任何規則的邊界。
5. **列出邊界情況。** 每則故事都對照檢查：空資料、超長輸入、重複、沒有權限、連線中斷、同一個動作做兩次，以及既有資料會怎樣。每個邊界情況要嘛變成一個情境，要嘛列為範圍外。
6. **寫範圍外說明。** 寫出這則故事刻意不做的事，免得審閱者期待它。
7. **跑 INVEST 檢查。** Bill Wake 的 INVEST：Independent（獨立）、Negotiable（可協商）、Valuable（有價值）、Estimable（可估算）、Small（夠小）、Testable（可測試）。每個字母標上通過或不通過。Small 不通過就再拆。Testable 不通過，代表驗收標準太模糊。Independent 不通過，就註明相依的項目。

## 輸出格式

```markdown
# 使用者故事：[功能]

## 故事 [n]：[簡短標題]
**身為** [角色]，**我想要** [能力]，**以便** [成果]。

**驗收標準**
- **情境：[名稱]**
  假設 [起始狀態]
  當 [動作]
  那麼 [可以觀察到的結果]

**邊界情況**
- [情況] → [由情境 x 涵蓋／範圍外]

**範圍外**
- [這則故事不做的事]

**INVEST：** I [通過/不通過] · N [通過/不通過] · V [通過/不通過] · E [通過/不通過] · S [通過/不通過] · T [通過/不通過] — [不通過的說明]

## 待釐清問題
- [輸入中沒有寫明的規則或限制]
```

## 範例

**輸入：**「擁有者應該能邀請他們的會計師成為唯讀使用者。唯讀使用者不能修改任何東西。擁有者可以移除他們。」

**輸出：**

```markdown
# 使用者故事：給會計師的唯讀席位

## 故事 1：邀請唯讀使用者
**身為** 帳號擁有者，**我想要** 用電子郵件邀請某人成為唯讀使用者，**以便** 我的會計師不用等我匯出檔案，就能直接檢查我的數字。

**驗收標準**
- **情境：擁有者寄出邀請**
  假設 我是帳號擁有者，在「團隊」頁面上
  當 我輸入電子郵件地址、選擇「唯讀」，並點選「寄出邀請」
  那麼 對方會收到邀請信
  而且 對方會以「唯讀，已邀請」出現在團隊清單中
- **情境：該電子郵件已在團隊中**
  假設 這個電子郵件屬於一位現有的團隊成員
  當 我對它寄出唯讀邀請
  那麼 我會看到「這個人已經在你的團隊中」，而且不會寄出邀請

**邊界情況**
- 電子郵件格式錯誤 → 欄位旁顯示錯誤訊息，由表單現有的驗證涵蓋 [假設]
- 邀請一直沒被接受 → 範圍外（是否過期列為待釐清問題）

**範圍外**
- 把現有成員的角色改為唯讀。

**INVEST：** I 通過 · N 通過 · V 通過 · E 通過 · S 通過 · T 通過

## 故事 2：唯讀使用者可以檢視但不能修改
**身為** 擁有唯讀權限的會計師，**我想要** 看到擁有者看得到的每一個頁面，**以便** 我能檢查帳目，而不必擔心改到它們。

**驗收標準**
- **情境：檢視發票**
  假設 我以唯讀使用者身分登入
  當 我打開「發票」頁面
  那麼 我會看到所有發票
  而且 畫面上沒有「建立」、「編輯」或「刪除」按鈕
- **情境：修改被擋下**
  假設 我以唯讀使用者身分登入
  當 我透過之前儲存的編輯頁面連結，試著修改一張發票
  那麼 我會看到「你只有檢視權限」，而且沒有任何內容被儲存

**邊界情況**
- 匯出為 CSV → 待釐清問題：匯出算不算「修改」？

**範圍外**
- 唯讀使用者留下的留言或備註。

**INVEST：** I 通過 · N 通過 · V 通過 · E 通過 · S 不通過 · T 通過 — 會影響每一個頁面；如果估算超過一個 sprint，就依頁面群組（發票、客戶、設定）拆開。

## 故事 3：移除唯讀使用者
**身為** 帳號擁有者，**我想要** 移除唯讀使用者，**以便** 前任會計師不再有存取權。

**驗收標準**
- **情境：擁有者移除存取權**
  假設 我的團隊中有一位唯讀使用者
  當 我點選「移除」並確認
  那麼 對方會在 [待確認：多快？] 內被登出，而且無法再登入這個帳號
- **情境：被移除的使用者試著登入**
  假設 一位唯讀使用者已被移除
  當 對方試著登入這個帳號
  那麼 登入會被拒絕，而且對方看不到這個帳號的任何資料

**範圍外**
- 通知被移除的人。

**INVEST：** I 不通過（需要故事 1） · N 通過 · V 通過 · E 通過 · S 通過 · T 通過 — 相依於故事 1。

## 待釐清問題
- 邀請會過期嗎？多久之後過期？
- 唯讀使用者可以匯出資料嗎？
- 每個帳號可以有幾位唯讀使用者？
```

## 寄出前檢查

- [ ] 每則故事只有一個角色，而且「以便」寫出使用者的成果。
- [ ] 每則故事至少有 1 個失敗路徑的情境。
- [ ] 每個「那麼」都能在畫面上或資料中觀察到，而不是「運作正常」。
- [ ] 沒有出現輸入中沒有的規則、限制或數字；缺的都列為待釐清問題。
- [ ] 每則故事都有 INVEST 這一行，每個不通過都有說明。
- [ ] 沒有任何故事是依技術層拆分的。

## 常見錯誤

- 「身為使用者，我想要一個按鈕」這種故事。要寫成果，而不是介面元件。
- 驗收標準只是把故事再說一次。每個情境都必須是測試人員有可能測出失敗的東西。
- 把 3 個功能藏在一則故事的情境裡。如果情境需要不同的角色或畫面，就拆開。