User Story

User story 透過終端使用者的角度，以非正式且通俗的方式來解釋一個軟體開發上的新功能。藉由 user story 的闡述方式，可以清楚地讓顧客/使用者了解這個新功能將會提供/帶來什麼樣的功能或價值。

這些 stories 以非技術性語言所寫成，而在閱讀這些故事後，團隊應知曉他們正在撰寫什麼功能、為什麼要做這件事、以及完成之後將會帶來什麼樣的價值

User story 包含三個基本元素 (fundamental elements / dimensions):

像是WHO想要這個功能，這個功能可以提供給使用者WHAT功能或是出資者希望這個系統提供何種功能，以及他們WHY需要這個系統/功能。這段話也可以被轉譯成

As a <role>, I want <goal> so that <benefit>

Who it is for, what is expected from the system, and optioanlly, why it is important

舉例來說：

As a administrator, I want to receive an email when a contact form is submitted, so that I can repsond to it

User story with Scrum

User story 被加入在 sprint 當中，且隨著一個 sprint 的進行被 consume。User story 可以幫助 Scrum team 在 planning 時能夠更準確的預估需求及時程。

在 planning meeting 的過程中，團隊將決定在這個 sprint 中要解決哪一個 story，並接著討論這個 story 有哪些需求及功能，並在討論結束後，將這些需求加入到 story 當中。

另一個常見的方式是 ─ 將每個 story 依據複雜程度進行排序，再將較大的 story 拆分成能夠在一個 sprint 中完成的大小。

乍聽之下，User story 像是多此一舉，為什麼不要把大的 project 拆成一個個小功能開發就好，還要說什麼故事？Stories 能提供給整個開發團隊一個重要的情境 (context)，並將這些小功能與其所能夠帶來的價值關聯起來。

實施 user story 有這些好處：

Stories將注意力永遠擺在使用者上 (stories keep the focus on the user)：一個 todo list 讓團隊僅專注在那些還沒被開發完成的 task，而 stories 會讓團隊專注於解決使用者的真實需求上，而不單止是冷冰冰的又劃掉 todo list 上的一個事項
Stories讓合作化成可能 (Stories enable collaboration)：在最終目標被清楚的定義後，使得團隊有辦法合作決定該如何滿足使用者需求、以及具體如何達成這個目標
Stories會驅使更好的解決辦法 (Stories drive creative solutions)：有了 Stories，便會鼓勵團隊更努力地激發出各種解決方案
Stories創造行動力 (Stories create momentum)：在完成每個小故事後，團隊能夠持續享受這些小挑戰及克服挑戰的過程，持續為團隊帶來正向行動力

💡

在 user stories 被清楚的定義之後，這些 Stories 應該讓整個團隊的成員都能看到

User stories 經常以一個簡單的句子表示，並有以下結構：

As a [persona], I [wants to], [so that]

如果拆開來看的話就是

“As a [persona]”: 我們做這個功能/產品是為了誰？我們為了Max，我們整個團隊具有一個對Max的共同認知，在這之前我們應該了解許多關於 Max 大大小小的事，我們了解 Max 在想什麼、他 (們) 的感受是什麼，我們和 Max 具有共感
“Wants to”: 在此要描述的是 Max 的意圖。並不是這個功能/產品本身，而是他們實際上打算達成什麼事情
“So that”: 總的來說，他們希望達成什麼樣的目標？有什麼大的問題需要被解決？

initiative > epic > story