User Story（使用者故事）是從使用者角度描述需求的最小可交付單位，用「As a / I want / So that」三段式公式撰寫。本文從格式拆解、5 種產業範例、INVEST 品質標準到 Story Mapping 全局規劃，帶你從零寫出高品質的用戶故事。
什麼是 User Story（使用者故事）？
User Story 是敏捷開發中描述需求的基本單位。它用一句話從使用者的角度說明「誰」需要「什麼功能」以及「為什麼需要」。與傳統的軟體需求規格書（SRS）不同，User Story 以「人」為中心，而非以「功能規格」為中心。
在 Scrum 框架中，User Story 的位置非常明確：Product Owner 將需求寫成一張張 User Story，放進 Product Backlog；團隊在 Sprint Planning 會議中挑選 Story 進入 Sprint Backlog；最後在 Sprint Review 中展示完成的成果。這個流程讓每一輪迭代都聚焦在「交付使用者真正需要的東西」。
很多人會把 User Story 和其他概念搞混，這裡先釐清：
| 概念 | 核心焦點 | 粒度 | 典型格式 |
|---|---|---|---|
| User Story | 使用者需求與動機 | 一個 Sprint 可完成 | As a…I want…So that… |
| Use Case | 系統與使用者的互動流程 | 可能跨多個 Sprint | 前置條件、主要流程、替代流程 |
| Task（任務） | 技術實作步驟 | 數小時到數天 | 建立 API、寫測試、部署 |
如果電商團隊把需求寫成「新增購物車功能」，工程師不知道要做到什麼程度，PM 也無法判斷什麼時候算「完成」。改寫成 User Story 後就變成：「身為首次購物的訪客，我想要將商品加入購物車並查看小計金額，以便決定是否結帳。」這樣一改，開發與 PM 對「完成」就有了共同定義，來回確認的次數自然會減少。
如果你的團隊正在從瀑布式開發轉型為敏捷，User Story 的寫法是最基礎也最關鍵的第一步。這跟企劃書的邏輯類似——你需要先定義清楚「為誰做、做什麼、為什麼做」，後續的執行才不會偏離方向。
User Story 的標準格式與 4 個核心組成
User Story 的黃金公式只有一句話：
As a [角色]，I want [需求]，so that [目的]。
中文版：身為 [角色]，我想要 [需求]，以便 [目的]。
這個公式看似簡單，但每個欄位都有明確的填寫原則。以下逐一拆解 4 個核心組成：
角色（Who）：不是「使用者」，而是具體的 Persona
「身為使用者」是最常見的錯誤。這等於什麼都沒說。你需要寫出具體的角色，例如：「首次購物的訪客」、「企業採購主管」、「免費方案試用者」。角色越具體，開發團隊越能理解這個需求背後的情境。
需求（What）：描述行為，而非技術實作
需求欄位要寫的是使用者想做的「事情」，不是工程師要實作的「技術方案」。
- ❌「加入 filter API 和排序演算法」
- ✅「能夠依價格、評分和上架日期篩選商品」
目的（Why）：最常被省略，卻最重要
「so that」這段是整張 Story 的靈魂。它回答「為什麼要做這件事」，讓團隊理解商業價值。更進一步，你可以將這裡的目的與公司的 OKR 或 KPI 對齊。例如，如果公司的 OKR 是「提升新客轉換率 15%」，那麼「以便在不註冊的情況下快速完成結帳」這個目的就直接連結到商業目標。這樣做的好處是，當 Backlog 需要排優先順序時，與 OKR 連結越緊密的 Story 自然排在前面。（想深入了解 OKR 設定，可以參考 ClickUp 的 OKR 框架範本。）
驗收標準（Acceptance Criteria）：定義「完成」的邊界
驗收標準是防止 scope creep 的關鍵。沒有驗收標準的 Story，就像沒有終點線的賽跑——大家不知道什麼時候可以停。驗收標準的詳細寫法我們在後面的「常見錯誤」段落會用 Given / When / Then 格式完整示範。
以下是錯誤 vs. 正確的對照：
| 錯誤寫法 | 問題 | 正確寫法 |
|---|---|---|
| 身為使用者，我想要更好的搜尋功能 | 角色模糊、需求不具體、缺少目的 | 身為回購客戶，我想要用關鍵字搜尋過去的訂單，以便快速重新下單 |
| 身為管理員，我想要一個 Dashboard | 缺少目的、需求太大無法估算 | 身為部門主管，我想要在首頁看到本月團隊的任務完成率，以便在週會前掌握進度 |
| 建立使用者資料庫 schema 和 API | 這是技術任務，不是 User Story | 身為新註冊會員，我想要儲存個人偏好設定，以便下次登入時看到個人化推薦 |
SaaS 新創專案裡常見這樣的情況：PO 寫了「身為使用者，我想要匯出報表」，省略了 so that，工程師就可能做成 CSV 匯出，但客戶其實需要的是帶有圖表的 PDF 報表，因為他們要直接拿去給老闆看。如果當初寫了「以便直接提交給主管審閱」，團隊就會知道格式和排版是重點。
User Story 範例：5 種產業情境實戰示範
光看公式還不夠，以下用 5 種常見產業情境示範完整的 User Story 寫法，每個範例都包含 Story 本文和驗收標準。
情境 1：電商平台——訪客結帳流程
Story： 身為首次購物的訪客，我想要不註冊就能完成結帳，以便減少購買阻力、提高下單意願。
驗收標準：
- 訪客可在結帳頁選擇「訪客結帳」，無需建立帳號
- 訪客需填寫 Email、收件地址、付款資訊即可完成訂單
- 結帳完成後顯示訂單確認頁，並發送確認信至填寫的 Email
- 訪客結帳的訂單可透過 Email + 訂單編號查詢物流狀態
為什麼這樣寫： 角色是「首次購物的訪客」而非「使用者」，因為回購客戶已有帳號，不需要這個功能。目的直接對應轉換率 KPI。
情境 2：SaaS 後台——管理員權限設定
Story： 身為企業方案的管理員，我想要為不同部門設定資料存取權限，以便確保敏感資料只有授權人員能查看。
驗收標準：
- 管理員可建立自訂角色，並為每個角色勾選可存取的模組
- 權限變更即時生效，被移除權限的使用者立即無法存取對應模組
- 系統記錄所有權限變更的操作日誌（含操作者、時間、變更內容）
情境 3：行動 App——推播通知偏好
Story： 身為已安裝 App 的活躍用戶，我想要自訂推播通知的類型和頻率，以便只收到我關心的資訊、不被打擾。
驗收標準：
- 用戶可在設定頁面開關以下通知類型：促銷活動、訂單狀態、新功能上線
- 用戶可選擇通知頻率：即時、每日摘要、每週摘要
- 設定變更後，下一次推播即依新設定發送
情境 4：內部系統——HR 請假申請
Story： 身為正職員工，我想要在系統上提交請假申請並追蹤審核進度，以便不需要用紙本或 Email 來回確認。
驗收標準：
- 員工可選擇假別（特休、病假、事假）、填寫日期範圍和事由
- 提交後，直屬主管收到通知並可在系統內核准或退回
- 員工可在「我的請假」頁面查看所有申請的狀態（待審核 / 已核准 / 已退回）
- 核准後自動扣除對應假別的剩餘天數
這類內部系統的需求，很適合用流程圖來視覺化審核流程，讓開發團隊更快理解邏輯。
情境 5：內容平台——作者發文草稿儲存
Story： 身為平台作者，我想要在撰寫文章時自動儲存草稿，以便在瀏覽器意外關閉後不會遺失內容。
驗收標準：
- 系統每 30 秒自動儲存一次草稿，頁面顯示「已儲存」提示
- 作者可在「草稿列表」中找到所有未發布的文章
- 草稿保留最近 10 個版本，作者可回復到任一版本
從 Epic 拆分 User Story 的邏輯
以情境 1 為例，「訪客結帳」其實是一個 Epic（史詩），可以拆成多張 Story：
- Epic： 訪客結帳流程
- Story 1： 訪客免註冊結帳（如上述範例）
- Story 2： 身為訪客，我想要在結帳時選擇超商取貨或宅配，以便用最方便的方式收到商品
- Story 3： 身為已完成訪客結帳的買家，我想要用 Email 和訂單編號查詢物流進度，以便掌握到貨時間
每張 Story 再往下拆成 Sub-task（技術任務），例如 Story 1 的 Sub-task 可能包含：「前端：建立訪客結帳表單」、「後端：建立訪客訂單 API」、「QA：撰寫訪客結帳的自動化測試」。
這個 Epic → Story → Sub-task 的三層結構，是台灣團隊在導入 Scrum 時最常混淆的地方。記住一個原則：Epic 是功能主題、Story 是使用者需求、Sub-task 是技術實作。
User Story 怎麼寫才算好？INVEST 標準完整解析
寫完一張 User Story 後，怎麼判斷它的品質？業界最廣泛使用的檢查框架是 INVEST 標準，由 Bill Wake 提出。六個字母分別代表一項品質要求：
I — Independent（獨立）
每張 Story 應該能獨立開發和交付，不依賴其他 Story 的完成順序。
判斷問題： 如果把這張 Story 從 Sprint 中移除，其他 Story 還能正常開發嗎？
N — Negotiable（可協商）
Story 不是合約規格書，它是對話的起點。細節應該在團隊討論中逐步釐清，而非一開始就鎖死。
判斷問題： 這張 Story 是否留有空間讓開發者提出更好的實作方式？
V — Valuable（有價值）
每張 Story 完成後，使用者或業務方應該能感受到具體價值。純技術重構（如「升級資料庫版本」）不算 User Story，應歸類為技術任務。
判斷問題： 如果把這張 Story 展示給使用者看，他們會覺得有用嗎？
E — Estimable（可估算）
團隊必須能對這張 Story 進行工作量估算（Story Point 或 T-shirt sizing）。如果無法估算，通常代表需求不夠清楚，需要進一步拆分或釐清。
判斷問題： 開發團隊能在 5 分鐘內對這張 Story 達成估算共識嗎？
實務上，Story Point 估算最常用的方法是 Planning Poker——團隊成員各自出牌（常見數列為 1、2、3、5、8、13），差異大的就討論，直到收斂。如果一張 Story 被估為 13 以上，通常代表它太大，需要拆分。
S — Small（夠小）
一張 Story 應該能在一個 Sprint（通常 1-2 週）內完成。如果太大，就拆分成更小的 Story。
判斷問題： 這張 Story 能在一個 Sprint 內從開發到測試全部完成嗎？
T — Testable（可測試）
Story 必須有明確的驗收標準，讓 QA 能寫出測試案例。如果無法測試，代表需求描述不夠具體。
判斷問題： QA 看完這張 Story 後，能立刻寫出至少 3 個測試案例嗎？
3C 原則：Story 是溝通工具，不是規格書
除了 INVEST，還有一個重要觀念是 3C 原則：
- Card（卡片）： Story 本身只是一張簡短的卡片，不需要寫成長篇文件
- Conversation（對話）： 真正的細節在團隊對話中產生，Story 只是觸發對話的起點
- Confirmation（確認）： 透過驗收標準確認雙方對「完成」的定義一致
Sprint Planning 前，可以讓 PO 帶著整批候選 Story 進會議室，團隊逐一用 INVEST 六項標準檢查：模糊到無法估算的刪掉或退回，重複的合併，太大的拆分。這樣篩過一輪，進入 Sprint 的 Story 品質會整齊很多，Sprint 中途卡住的機會也跟著變少。
這個過程跟艾森豪矩陣的思維很像——不是做更多，而是先過濾掉不該做的，再聚焦在真正重要的事上。
寫完一張 Story 後的 6 個自我審查問題
- 角色是否具體到能想像出一個真實的人？
- 需求是否描述行為而非技術方案？
- 目的是否能連結到商業目標或使用者動機？
- 驗收標準是否有 3 條以上？
- 團隊能在一個 Sprint 內完成嗎？
- QA 看完能立刻寫測試案例嗎？
User Story Mapping：從單張卡片到全局視野
單張 User Story 解決的是「這個需求怎麼描述」的問題，但當你的 Backlog 有 50 張、100 張 Story 時，你需要一個方法看到全局。這就是 Story Mapping 的價值。
Story Mapping 由 Jeff Patton 提出，它的核心概念是用兩個維度整理所有 Story：
- 橫軸（左到右）： 使用者旅程的活動流程，按時間順序排列
- 縱軸（上到下）： 每個活動下的 Story，按優先順序排列
4 步驟建立 Story Map
步驟 1：列出使用者活動（Backbone）
把使用者從開始到結束會經歷的主要活動列在橫軸上。以電商為例：瀏覽商品 → 搜尋篩選 → 查看商品詳情 → 加入購物車 → 結帳 → 訂單追蹤。
步驟 2：拆解每個活動的 User Story
在每個活動下方，列出所有相關的 Story。例如「結帳」活動下可能有：訪客結帳、會員結帳、選擇配送方式、套用折扣碼、選擇付款方式。
步驟 3：依優先順序垂直排列
每個活動下的 Story，越重要的排越上面。排序依據可以是商業價值、使用頻率或技術風險。
步驟 4：用水平線切割版本
在 Story Map 上畫一條水平線，線以上的就是 MVP（最小可行產品），線以下的留到後續版本。這條線就是團隊對「第一版要做什麼」的共識。
遠端團隊的 Story Mapping 實戰
如果你的團隊是遠端或混合工作模式，實體便利貼就不太適用了。這時可以改用 Miro 的白板功能做遠端 Story Mapping 工作坊。Miro 的便利貼功能讓每個人可以同時貼上自己的 Story，再用投票功能決定優先順序。
Story Map 最大的用處，是讓對 MVP 範圍各有想像的人看到同一張全貌。假設 PM 想做 12 個功能、設計師覺得 8 個就夠、工程師認為 6 個才合理，把所有 Story 攤在同一張地圖上、畫出版本線之後，討論就會從「誰的清單對」變成「哪幾張卡片該放在線的上面」，共識也比較容易達成。
誰來寫 User Story？角色分工與協作流程
User Story 的主要撰寫者是 Product Owner（PO）或 PM，但這不代表一個人關起門來寫。好的 Story 是協作的產物。
| 角色 | 負責內容 | 參與時機 |
|---|---|---|
| PO / PM | 撰寫 Story 本文、排優先順序 | Backlog Refinement、Sprint Planning |
| UX 研究員 | 提供 Persona 資料、使用情境 | Story 撰寫前的研究階段 |
| 開發者 | 確認技術可行性、估算工作量 | Backlog Refinement、Planning Poker |
| QA | 協助定義驗收標準、撰寫測試案例 | Backlog Refinement、Sprint 期間 |
一個常見的誤區是讓工程師自己寫 Story。工程師寫出來的往往是技術任務（「建立 REST API endpoint」），而非使用者需求。這不是工程師的問題，而是角色定位不同——工程師的專長是解決「怎麼做」，PO 的專長是定義「做什麼」和「為什麼做」。
寫 Story 最好的時機是 Backlog Refinement 會議（也叫 Grooming）。在這個會議中，PO 帶著初步撰寫的 Story，團隊一起審查、提問、拆分、補充驗收標準。這正是 3C 原則中「Conversation」的實踐。
好的領導力在這裡的體現是：PO 不堅持自己寫的每個字都是對的，而是把 Story 當作對話的起點，讓團隊共同打磨。
Definition of Ready（DoR）：Story 進入 Sprint 的 5 個就緒條件
不是每張 Story 都適合直接拉進 Sprint。以下是我們建議的 5 個就緒檢查點：
- Story 符合標準格式——角色、需求、目的三段都有填寫
- 驗收標準已定義——至少 3 條，QA 確認可測試
- 團隊已估算工作量——Story Point 已達成共識
- 相依性已釐清——不依賴其他未完成的 Story
- 設計稿已就緒——如果涉及 UI，設計師已提供 mockup
只有通過這 5 項檢查的 Story，才能進入 Sprint Backlog。這能大幅減少 Sprint 中途才發現「這張 Story 根本還沒準備好」的窘境。
User Story 管理工具推薦
工具的選擇取決於你的團隊規模和工作方式。以下分三類推薦：
實體工具：便利貼 + 白板
適合 5 人以下的小團隊，或是在 Story Mapping 工作坊中使用。便利貼的好處是直覺、低門檻，但缺點是無法遠端協作、不易追蹤歷史變更。
輕量數位工具
如果團隊預算有限或剛開始接觸敏捷，Notion 是很好的起點。你可以用 Notion 的資料庫功能建立 Story 卡片，每張卡片包含角色、需求、目的、驗收標準等欄位，再用看板視圖管理狀態。Notion 的免費方案對小團隊來說已經夠用。
專業敏捷工具
當團隊超過 10 人、需要跨部門協作時，你需要更完整的工具。以下是幾款專業工具的比較：
| 工具 | 適合團隊規模 | User Story 支援功能 | 月費（每人） | 推薦情境 | 免費試用 |
|---|---|---|---|---|---|
| monday.com | 5-200 人 | 看板、自動化、Sprint 管理、自訂欄位 | 免費 — NT$608 | 跨部門協作、非純技術團隊 | 免費試用 → |
| ClickUp | 5-100 人 | Sprint、Story Point、自訂工作流程 | 免費 — NT$390 | 技術團隊跑 Scrum | 免費試用 → |
| Notion | 1-20 人 | 資料庫、看板、範本 | 免費 — NT$300 | 小團隊、預算有限 | 免費試用 → |
| Miro | 5-50 人 | Story Mapping、便利貼、投票 | 免費 — NT$300 | 遠端 Story Mapping 工作坊 | 免費試用 → |
用 monday.com 管理 Backlog 時，最實用的是自動化規則——例如設定「當 Story 狀態改為 Done 時，自動通知 PO 進行驗收」，PO 就不用再手動追蹤哪些 Story 已經開發完成。免費方案不需要信用卡，可以直接試用。
如果你的團隊是純技術團隊、已經在跑 Scrum，ClickUp 的 Sprint 功能支援 Story Point 估算、Sprint Velocity 追蹤和 Burndown Chart，對工程團隊來說非常實用。
（推薦試試 monday.com 的免費方案，先拿一個 Sprint 的 Backlog 試用看看。）
你是哪種團隊？
- 5 人以下、剛開始接觸敏捷 → 先用 Notion 免費版建立 Story 資料庫
- 5-15 人跨部門協作 → monday.com（我們的首選），自動化功能省下大量溝通成本
- 技術團隊跑 Scrum → ClickUp，Sprint 管理功能最完整
- 需要遠端 Story Mapping → Miro，視覺化協作最強
常見錯誤與避坑指南
以下是撰寫 User Story 時最常見的 5 個錯誤，每個都附上修正方法。
錯誤 1：Story 太大，無法在一個 Sprint 完成
錯誤版本： 身為管理員，我想要一個完整的使用者管理系統，以便管理所有帳號。
修正版本： 拆成 3 張 Story——
- 身為管理員，我想要查看所有使用者的清單和狀態，以便掌握帳號總覽
- 身為管理員，我想要停用或啟用特定使用者帳號，以便處理離職或違規帳號
- 身為管理員，我想要批次匯入使用者資料，以便在新部門上線時快速建立帳號
拆分原則： 按使用者的操作動作拆分，每個動作 = 一張 Story。
錯誤 2：寫成技術任務
錯誤版本： 建立 PostgreSQL 資料庫 schema，包含 users、orders、products 三張表。
修正版本： 身為回購客戶，我想要查看過去 12 個月的訂單紀錄，以便快速找到想重新購買的商品。
判斷方法： 如果 Story 裡出現了技術名詞（API、schema、endpoint），它很可能是 Sub-task 而非 Story。
錯誤 3：沒有驗收標準
這是最危險的錯誤。沒有驗收標準，開發者不知道做到什麼程度算完成，QA 無從測試，PO 驗收時只能憑感覺。
解法：用 Given / When / Then 格式撰寫驗收標準。
這是 BDD（行為驅動開發）的標準格式，台灣許多敏捷團隊已經在使用：
- Given（前提條件）： 在什麼情境下
- When（觸發動作）： 使用者做了什麼
- Then（預期結果）： 系統應該怎麼反應
範例： 以「訪客免註冊結帳」為例——
Given 訪客已將至少一件商品加入購物車 When 訪客點擊「訪客結帳」按鈕並填寫完 Email、地址、付款資訊 Then 系統建立訂單、顯示訂單確認頁、發送確認信至訪客 Email
Given 訪客在結帳過程中未填寫必填欄位 When 訪客點擊「送出訂單」 Then 系統顯示錯誤提示，標記未填寫的欄位，不建立訂單
這個格式的好處是，QA 可以直接把每條 Given / When / Then 轉換成一個測試案例，不需要再猜測。
錯誤 4：角色太模糊
錯誤版本： 身為使用者，我想要搜尋功能。
修正版本： 身為尋找特定商品的回購客戶，我想要用關鍵字搜尋並篩選過去購買過的商品，以便快速重新下單。
建立有效 Persona 的方法： 問自己三個問題——這個人的目標是什麼？他在什麼情境下使用這個功能？他的技術熟悉度如何？如果你的團隊有做過使用者研究，可以直接引用研究中的 Persona。問卷設計是收集 Persona 資料的好方法。
錯誤 5：Story 之間相依性太強
錯誤版本： Story A「建立使用者資料庫」必須先完成，Story B「使用者登入」才能開始。
修正版本： 重新從使用者角度撰寫，讓每張 Story 都能獨立交付價值——
- Story A：身為新訪客，我想要用 Email 註冊帳號，以便儲存我的購物偏好
- Story B：身為已註冊會員，我想要用 Email 和密碼登入，以便查看我的個人化推薦
拆分技巧： 如果兩張 Story 有技術相依性，把共用的技術基礎設施放進 Sprint 0 或作為 Spike（技術探索任務）處理，不要混在 User Story 裡。
User Story 範本與快速上手清單
以下是可以直接複製使用的 User Story 範本：
## User Story
**Story ID：** [編號]
**Epic：** [所屬 Epic 名稱]
**Story：**
身為 [具體角色]，
我想要 [描述行為/需求]，
以便 [商業價值/使用者動機]。
**驗收標準：**
1. Given [前提條件] When [觸發動作] Then [預期結果]
2. Given [前提條件] When [觸發動作] Then [預期結果]
3. Given [前提條件] When [觸發動作] Then [預期結果]
**Story Point：** [估算值]
**優先順序：** [Must / Should / Could / Won't]
**備註：** [設計稿連結、技術限制、相關 Story 編號]
從零開始寫第一張 Story 的 5 步驟
- 確認角色： 從你的產品最主要的使用者開始，寫出一個具體的 Persona（不是「使用者」）
- 描述需求： 用「我想要 + 動詞 + 受詞」的句型，描述使用者想做的事
- 說明目的： 問自己「為什麼他需要這個？」，答案就是 so that 後面的內容
- 寫驗收標準： 用 Given / When / Then 格式寫至少 3 條，涵蓋正常流程和異常流程
- 用 INVEST 自我檢查： 逐一對照 6 項標準，不通過的就修改或拆分
如果你想進一步提升產品管理的專業能力，Coursera 的數位產品管理課程涵蓋了從 User Story 到產品策略的完整知識體系，適合想系統性學習的 PM。
在你的下一次 Backlog Refinement 會議前，試著用這個範本重新審查現有的 Story。你會發現很多「看起來沒問題」的 Story，其實缺少驗收標準或角色太模糊。進入心流狀態專注寫完一輪審查，整個 Backlog 的品質會有質的飛躍。
結論
User Story 不只是一種寫需求的格式，它是敏捷團隊溝通的核心工具。寫好 User Story 的關鍵在於：
- 格式要完整： 角色、需求、目的三段缺一不可，尤其「so that」是最常被省略卻最重要的部分
- 驗收標準用 Given / When / Then： 讓開發者和 QA 對「完成」有共同定義，避免 scope creep
- 用 INVEST 標準自我檢查： 每張 Story 都要通過獨立、可協商、有價值、可估算、夠小、可測試六項檢查
- Story Mapping 看全局： 單張 Story 解決微觀問題，Story Map 解決宏觀的版本規劃和優先順序
- 協作而非獨寫： PO 負責撰寫，但 UX、開發、QA 都要在 Backlog Refinement 中參與打磨
你的下一步行動：在下一次 Backlog Refinement 前，用本文的 INVEST 檢查清單審查你現有的前 10 張 Story。把不通過的標記出來，帶到會議中和團隊一起修改。
想把這篇文章的方法論付諸實踐？第一步：在 monday.com 建立一個新看板，用自訂欄位設定角色、需求、目的、驗收標準和 Story Point，10 分鐘就能建好你的第一個 User Story 管理系統。免費方案不需要信用卡，直接開始。
User Story 常見問題
User Story 和 Use Case 有什麼不同？
User Story 是一句話的需求描述，強調使用者動機和商業價值，粒度小到一個 Sprint 可完成。Use Case 是完整的系統互動流程文件，包含前置條件、主要流程、替代流程和例外處理，粒度通常更大。簡單說，User Story 是對話的起點，Use Case 是詳細的規格文件。
一張 User Story 應該多大？
理想的大小是一個 Sprint（1-2 週）內可以從開發到測試全部完成。如果用 Story Point 估算，通常 1-8 點是合理範圍，超過 13 點就應該拆分。判斷方法：如果團隊無法在 5 分鐘內達成估算共識，這張 Story 很可能太大或太模糊。
驗收標準要寫幾條？
建議每張 Story 寫 3-5 條驗收標準。至少要涵蓋一個正常流程（Happy Path）和一個異常流程（Edge Case）。太少代表需求不夠明確，太多（超過 8 條）通常代表這張 Story 太大，應該拆分。
非軟體開發團隊也能用 User Story 嗎？
可以。User Story 的核心是「從使用者角度描述需求」，這個思維適用於任何需要釐清「為誰做、做什麼、為什麼做」的場景。例如行銷團隊可以寫：「身為對產品有興趣的潛在客戶，我想要在官網看到客戶成功案例，以便評估這個產品是否適合我的公司。」格式一樣，只是「開發」變成「內容製作」。
User Story 應該由誰來寫？
主要由 Product Owner 或 PM 撰寫，但不是一個人閉門造車。最佳實踐是 PO 先寫初稿，再在 Backlog Refinement 會議中與開發者、QA、設計師一起審查和補充。特別是驗收標準的部分，QA 的參與能確保每條標準都是可測試的。