我曾經以為 User Story 只是一種格式
過去接觸敏捷文化、或部門試著導入敏捷工具時，常常會聽到 “User Story” 這個詞。
但我對 User Story 的理解，大多停留在把要做的事情改寫成:
“As a [persona], I [want to], [so that].”
這種 Template。
不過把事情改寫成這樣的格式後，其實討論並沒有發生太多變化，只是換一種形式記錄工作，在向組員分享工作時，還是很容易淪為流水帳，有時候更糟，分享的當下連自己都陷入尷尬，為了符合 Template 而改用自己也不習慣的方式陳述工作。
為什麼要稱為 Story ? 用這樣的格式記錄要做的事情，就叫做 Story 了嗎？
最近讀了 《User Story Mapping》 後，這些問題開始有不同的看法。
說個好故事讓同伴能參與
之所以稱為 Story，重點不是怎麼「寫」這個故事，而是如何「說」這個故事。
Story 的重點，是透過說故事的方式，讓聽眾不只是接收資訊，而是能夠產生興趣、提出追問，甚至帶進不同的觀點。
我想舉個例子，如果我現在問你：「我該買牛奶嗎？」
你可能會想：「牛奶？乾我屁事？」、「我怎麼知道你該不該買牛奶？」
但如果我改成說故事的方式呢？
「我最近覺得體力不太好，想喝牛奶來補充營養，你覺得我該買牛奶嗎？」
這時候你心中的選項可能就會變多了：
- 為什麼你會覺得體力不好是因為營養不足？(產生興趣、追問細節)
- 補充營養的話我比較喜歡吃魚油欸 (提供不同的解決方案)
- 我覺得可以買，我自己都喝 XX 牌牛奶 (針對解決方案提供參考意見)
這兩個場景有什麼差異？ 在問問題時，說故事的方式加入了一點 Context。
而當故事提供了足夠的 Context，聽眾才有機會從「被動接收資訊」轉成「主動參與討論」。
好的 Story，不只是讓大家知道我要做什麼，而是讓大家有能力一起判斷：這件事值不值得做？如果要做，應該往哪個方向做？
“Good story conversations are about who and why, not just what.”
在切入技術方案，甚至投入自己寶貴的工時前，先問問自己：
這是給誰用？他會怎麼使用？這件事放在他的工作流程中，想改善哪一段？
我過去在規劃工作時，很容易跳過這段思考，只想著自己要做什麼、要用什麼技術，卻沒有先把使用者、情境和想改善的問題想清楚，也沒有帶著這些資訊和夥伴討論。
結果就是：功能可能真的做出來了，但最後產生的 Outcome 不一定理想。
這也是我在2025 年末的反思中提到，自己在規劃時缺少產品思維的地方。
說故事時要注意 Context 的落差
這裡有個我後來才意識到的陷阱：
說故事不等於自動建立 Shared Understanding
故事只是邀請對方進入討論的入口，至於對方有沒有真的進入，取決於提供 Context 是否足夠、對方是否知道自己可以參與討論。
分享我實際的經驗，在我了解 Story 的核心精神後，我試著在開會時，改變我陳述工作的方式。
過去都是以 How 的角度切入，直接和組員分享我想做些什麼、我要用什麼技術或框架做。
慢慢練習以說故事的方向去陳述，事情有所改善了嗎？
並沒有，坦白說，一開始效果很差。
在我改以說故事的方式陳述工作時，我心裡有個期待，期待團隊會開始進行 Why、What 的討論，但很多時候夥伴們聽完故事，還是靜靜地點頭，或是仍然針對 How 提出建議。
為什麼會這樣？
私底下和主管、組員聊了一下，發現一個關鍵：
我以為對方擁有的 Context，常常遠比對方真正擁有的 Context 還多很多。
這裡其實有兩個層面的 Context 落差：
第一層是，我對 User Story 有了新的理解，也開始期待大家能從 Who、Why、What 的角度一起討論，但聽眾並不知道我改變了討論方式，也不知道我期待他們怎麼參與。
第二層是，我身為故事的作者，腦中已經有很多背景資訊，所以在分享時很容易不小心跳過一些我以為大家都知道的細節。但那些細節其實只存在我的腦袋裡，並沒有真的進到團隊的共同脈絡中。
所以透過說故事的方式建立 Context 時，除了要持續有意識的建立 Shared Understanding 外，還要有意識的提醒自己：很多資訊只存在你的腦袋中，其他人並不一定知道！
目前對於 User Story 的三個收穫
1. User Story 不是寫完才拿出來 Review
對現在的我來說，User Story 不應該是自己在腦中整理完畢，最後才拿出來給大家 Review 的文件。
如果 Story 的目的是建立 Context，那它應該更早出現在討論中，就算是以一個還不完整的故事也可以被接受。
回到開頭的例子：我不需要等到研究完牛奶、魚油、睡眠、營養學才問別人，而是當我覺得「體力不好，想尋找改善方式」時，就可以開始邀請別人參與討論了。
2. User Story 是把團隊拉進問題，不是把答案交給團隊
以 Story 為基底的討論，並不是把所有細節都丟給其他人，期待旁人幫我發想完整答案。
我仍然需要事先整理足夠的脈絡、刪減掉過多雜訊，以「有效且有效率的方式」，讓團隊的其他人知道這件事從何而來、想改善什麼、目前卡在哪裡。
差別在於：不是拿一個已經定案的 Solution 請大家補強，而是拿一個理解中的問題，邀請團隊一起校準。
3. 好的 Story 會讓團隊先校準問題，再討論解法
在改用 Story 描述工作時，如果沒有提供足夠的 Who 和 Why，團隊不是不想參與，而是不知道該從哪裡參與。
此時成員通常會傾向使用最安全、最熟悉的回應方式 - 針對 How 給予建議：用哪個框架、怎麼切 Task、這個 API 怎麼設計。
這些討論都重要，但如果團隊從來沒有一起確認 Who 和 Why，How 討論得越熱烈，越可能只是更有效率地走向錯的方向，如同一個 Feature Factory。
給自己的 Checklist
現在的我在準備 User Story 時，會用幾個問題提醒自己，更靠近團隊能進入問題的入口：
- 這件事是誰遇到的問題？
- 為什麼這個問題現在值得處理？
- 我希望團隊在哪些地方參與討論？
- 我有哪些 Context 其實只存在自己腦中，還沒有變成團隊共同知道的資訊？
對我來說，User Story 真正重要的不是那個 Template。
Template 也許是一種讓人容易入門的 Best Learning Practice，但它不是目的本身，我們可以用任何形式來說出自己的故事。
真正值得在意的是：它有沒有幫助我們把一件工作，說成一個團隊能夠共同理解、共同判斷、共同校準的問題。
如果沒有，那它可能只是另一種格式比較漂亮的任務清單。
謝謝你的閱讀，我們下次見。
About Byte & Ink
我會定期在部落格分享不同主題的文章，目前包含：
- 職涯心得
- 個人成長
- 筆記軟體 - Obsidian 教學
- 技術相關 (
K8S,DevOps,軟體測試…)
如果你覺得內容有幫助，歡迎你點此訂閱我的文章，你的訂閱會帶給我更多動力，持續分享有意義的內容！