以下文章內容皆來自下面這兩個網頁的內容，這裡僅作個人筆記整理:

1)
https://medium.com/kevins-venture/%E4%BD%A0%E7%9A%84%E7%94%A8%E6%88%B6%E9%95%B7%E4%BB%80%E9%BA%BC%E6%A8%A3%E5%AD%90-%E7%94%A8-user-story-%E5%8B%BE%E5%8B%92%E5%87%BA%E7%94%A2%E5%93%81%E6%A8%A3%E8%B2%8C-8ed2a9655a84#:~:text=%E4%BB%80%E9%BA%BC%E6%98%AFUser%20Story%3F,%E9%96%8B%E7%99%BC%E6%99%82%E6%89%8D%E6%9C%83%E7%A2%BA%E5%AE%9A%E3%80%82

2)

https://ihower.tw/blog/archives/2090

Outline:

• 前言
• 為什麼需要User stories?
• 什麼是 User Story?
• 如何寫出User Stories?
• 加入驗收標準 (acceptance Criteria)
• 用有效率的工具或平台管理這些Story

---

前言:

開發產品通常是為了解決 TA 的特定問題。此時，我們需要User stories來幫助我們。

為什麼需要User stories?

需要 User Story 來幫助我們釐清使用者的身份、動機、限制，才能設計出一個順手、好用的產品。

什麼是 User Story?

User Story 是一段簡單的功能敘述，以客戶或使用者的觀點 撰寫下有價值的功能(functionality/feature)
Note 1: 它不是規格文件(documentation)，它只代表客戶的一個需求而已，實作細節將延後至開發時才會確定。
Note 2: 有學習過UML的話，User Stories 不是 Use Case (不同之處)，也不是 Scenarios。
Note 3: User stories 的用意就不在於寫下完整的細節，而是一個文字記錄說提醒開發者跟客戶，這裡需要再討論溝通細節。

如何寫出User Stories?

1. 了解你的User、定義你的角色（利用Pesonas）
2. 從角色出發，粗略但簡明的寫出 User Stories …. in Epic!
   Ex 1: 身為一個 {{特定角色}}，我希望能有 {{特定功能}} 以便能讓我 {{得到某種價值}}
   Ex 2: 身為一個 {{學生}}，我希望 {{只有我能查到自己的成績}}，這樣才能 {{知道我的分數又不用讓同學知道}}
3. 拆解Epic，成為可執行的 Ready User Stories
   Epic 還無法被視為一個清楚可執行的 Task，需要再被拆解、細分為 Ready User Story。
   怎樣算是 “Ready” 呢？我們可以用以下三個原則去評估他：
   a) 明確
   b) 可執行
   c) 可測試

加入驗收標準 (acceptance Criteria)

寫下更明確的 “驗收標準”。有了這些準則，程式設計師就可以知道客戶會做哪些驗收測試、期望跟假設。
(EX: 哪些資料輸入、期望哪些輸出、哪些邊際條件需要處理、任何潛在的商業邏輯……)

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

Note: 不論是用紙本或是線上平台管理，PO要盡量讓這些 Story 能夠被所有團隊成員看到