由誰撰寫 Story#
雖然任何人都可以撰寫 User Story，但主要的撰寫責任在客戶身上。開發人員可以幫助客戶撰寫，特別是在蒐集 Story 的工作坊中，但客戶必須確保 Story 反映了真正的業務需求。
開發人員不應獨自撰寫 Story。即使開發人員提出了好的想法，也應該與客戶討論並由客戶認可。Story 代表的是客戶需要什麼，而非開發人員想做什麼。
撰寫好 Story 的原則#
從目標出發，而非從解決方案出發#
Story 應描述使用者的目標，而非具體的介面或技術實作。例如：
- 好的寫法：「A user can search for a job.」
- 不好的寫法：「A user can enter a keyword in a text field and click the Search button.」
加入使用者角色#
指明哪一種使用者需要這個功能，讓團隊更清楚 Story 的背景：
- 「A Job Seeker can post a resume.」
- 「A Recruiter can search resumes.」
寫出商業價值#
在可能的情況下，加入「so that…」來說明這個 Story 帶來的商業價值：
- 「A Recruiter can post a job, so that she can find candidates.」
Story 的粒度#
Story 的大小應該適合規劃和估算。過大或過小都會造成問題：
- Epic（史詩級故事）：太大而無法在一個迭代內完成，需要拆分
- 適當大小：可以在幾天內完成，團隊容易估算
- 太小：拆得太細反而增加管理負擔
拆分 Story 的技巧#
當一個 Story 太大時，可以用以下方式拆分：
- 依資料邊界拆分：例如把「搜尋工作」拆成依地點搜尋、依職位搜尋
- 依操作拆分：例如把 CRUD 操作拆成建立、讀取、修改、刪除
- 移除橫切關注點：例如先做沒有安全性檢查的版本，再加入權限控制
約束條件（Constraints）#
有些需求不適合寫成 Story，而是以約束條件的形式表達。例如：
- 「The system must be written in Java.」
- 「The application must work on IE and Firefox.」
約束條件通常寫在一張獨立的卡片上，標註為「Constraint」。它們限制了系統的整體設計，但不需要獨立估算。
使用者介面需求#
在 Story 中應盡量避免過早指定使用者介面的細節。介面設計應在接近開發時，透過與客戶的對話來決定。
過早在 Story 中加入 UI 細節會限制設計空間，導致團隊無法探索更好的介面方案。