KJ Huang

A story is a placeholder for a conversation.

User Story(使用者故事)不是一份詳細的需求規格,而是一段高層次、靈活的描述——「As a [Role], I want [Feature], so that [Benefit]」——目的是促進團隊對話,把細節延遲到必要時才提供。本文說明 User Story 的概念、INVEST 原則與切割方式、Epic 與 Theme 的階層關係,以及 AC 與 DoD 兩種驗收標準。

什麼是 User Story?

過往我們對於提需求這件事存在著一個固定的想法:先把需求規格定好,我們就照這個規格做好軟體給使用者。當然想也知道通常規格一定是一直改來改去的。

User Story 這一概念的出現就是希望解決前面的問題,User Story 不是一個刻板的、詳細的需求說明,而是一個高層次、靈活的描述,用以引導後續的開發工作。所以 User Story 的目的就是希望促進互動,並延遲到必要時才提供細節。

User Story 透過簡潔的敘述方式,鼓勵團隊成員之間的對話和討論。這種描述方式專注於使用者需求和期望的「什麼」和「為什麼」,而非具體的實現方式或技術細節。

怎樣才是有效的 User Story?

User Story 通常遵循一個基本的格式:”As a [Role], I want [Feature], so that [Benefit].” 這裡的 [Role] 代表著一個特定的使用者群體而非個別使用者,這有助於從這個群體的特性出發,考慮其在系統中的利益。

有效的 User Story 應該是獨立的、可協商的、有價值的、可估計的、小而精的、並且可測試的(INVEST)。例如,一個過於龐大的 User Story 應該被分解成更小、更具體的故事。

在 User Story 的開發過程中,我們還需要考慮如何切割故事。橫向切割,即按照專業領域(如 UI, server side, DB)來分割故事,這種方法雖然在技術上可行,但有可能無法交付完整的功能。相反的,功能的縱向切割,即按照物件的功能來切割,我們交付較小的功能片段,使用者真正能使用這個功能。

User Story 的階層:Epic 與 Theme 是什麼?

User Story 還應該包括「Epic」和「Theme」。Epic 是一系列 User Story 的集合,用於描述達成特定目標的完整工作流程。而 Theme 則是追蹤一系列相關的故事,但這些故事可以獨立完成。

如何驗收 User Story?AC 與 DoD

我們需要為制定的功能考慮「驗收標準(Acceptance Criteria, AC)」和「完成標準(Definition of Done, DoD)」。驗收標準為開發團隊提供具體的實作細節,幫助團隊明確理解何時 User Story 被視為完成。

DoD 確保產品符合品質標準,像是達成一開始團隊共同協商的測試覆蓋率、Code Review、部署和滿足 User Story 驗收標準等等。

重點整理

• User Story 是「對話的佔位符」:用 As a / I want / so that 描述「什麼」與「為什麼」,細節延遲到必要時才補上。
• 好故事符合 INVEST:獨立、可協商、有價值、可估計、小而精、可測試;切割時採縱向(依功能)而非橫向(依技術層),才能交付使用者真正能用的功能。
• Epic 是達成特定目標的一系列故事集合,Theme 追蹤相關但可獨立完成的故事;AC 定義單一故事何時算完成,DoD 是全團隊共同的品質底線。

常見問題

User Story 要寫多細?細節到底什麼時候補?

卡片上只要留下足以喚起對話的資訊就夠:角色、想做的事、為什麼。細節補在驗收標準裡,而且是在這張故事即將進入開發時才補,不是排進 backlog 當下就寫滿。太早寫死的細節有很高機率在真正開工前就被推翻,那些字等於白寫。判斷標準很簡單:如果沒有這個細節,團隊就沒辦法開始討論,那它該現在寫;否則就留到 refinement。

什麼是 INVEST 原則?

INVEST 是有效 User Story 的六個條件:Independent(獨立)、Negotiable(可協商)、Valuable(有價值)、Estimable(可估計)、Small(小而精)、Testable(可測試);過大的故事應分解成更小、更具體的故事。

AC 和 DoD 差在哪?

AC(驗收標準)針對單一 User Story,定義該功能何時被視為完成的具體條件;DoD(完成定義)是團隊層級的共同品質標準,例如測試覆蓋率、Code Review 與部署要求,適用於所有故事。