使用者故事與需求之間的差異是什麼？

雖然大多數新功能應從使用者的角度來定義，但在實際操作中，當定義開發團隊需要建構的需求時，我們經常忽略了使用者角度的「為什麼」。使用者故事的重點在於體驗——使用者使用產品想要達成的目標。傳統需求則著重於功能——產品應該做什麼。其餘的差異則在於微妙但關鍵的「誰」、「如何」和「何時」清單。

使用者故事應以一或兩句話撰寫，捕捉使用者是誰、他們想要什麼以及為什麼。定義功能或使用者故事的簡單結構如下：

作為一個 ______，我希望 ______，以便我可以 ______。

範例：

作為一名使用者，我希望能夠重設密碼，以便在遺忘時重新取得系統的存取權。

儘管目標不同，使用者故事與需求最終都旨在打造客戶喜愛的產品。

什麼是使用者故事？

使用者故事是從最終使用者角度表達的需求。使用者故事也可稱為大型故事、主題或功能，但它們都遵循相同的格式。

本質上，使用者故事是一種明確表達的需求。由於多種原因，使用者故事格式已成為敏捷開發中表達需求最流行的方式：

• 它著重於使用或受解決方案影響的人的觀點。
• 它以該角色有意義的語言定義需求。
• 它有助於釐清需求背後的真正目的。
• 它有助於定義高階需求，而不至於過早陷入低階細節。

識別使用者目標，並立即考慮使用者故事中每項需求的商業價值。

使用者故事通常被認為包含三個要素——3C:

• CARD – 應寫在索引卡或便利貼上。
• C對話 – 從產品負責人取得詳細資訊（產品負責人).
• C確認 – 確保正確實作。必須符合使用者接受標準。

使用者故事格式

使用者故事的格式如下：

作為一個 <角色>, 我想要 <目標>, 以便 <利益>

這兩個例子展示了不同層級的使用者故事，但使用相同的格式：

在專案層級：

作為 <行銷經理>, 我想要 <提升客戶服務>, 以便 <我們能留住客戶>。

• 為使用者故事撰寫 SMART 目標與 INVEST 標準
• 主題 vs 巨大功能 vs 使用者故事 vs 任務
• 產品待辦事項中的 DEEP 是什麼意思？
• 如何為 Scrum 專案撰寫產品願景？
• 如何使用 Scrum 看板進行敏捷開發？
• 在 Scrum 中，誰負責建立產品待辦事項或使用者故事？
• 什麼是敏捷估算？
• 敏捷中的故事點是什麼？如何估算使用者故事？
• 使用者故事拆分 – 垂直切片 vs 水平切片