（改寫自公司內部 memo）
Hi all guys,
最近我會對有意導入 Scrum 的任務小組個別進行一整天的 Agile Workshop。這些小組都有一項課前作業：請先準備團隊在三個月以內會進行的 User Stories 清單／陳述。
眾所周知，user story 有一個經典句型：
As a {XXX user persona}, I want to {do YYY} so that {ZZZ result or benefit}.
有同仁問道：有些 user story 不容易以「“user” 視角」來寫。怎麼辦？真的要這麼嚴格遵守 user story 格式嗎？
譬如說，以下兩個 autocomplete 任務，要怎麼轉寫成 user story？
- Autocomplete 要能承受 100 rps。
- Autocomplete 要優先置入廣告關鍵字。
我的建議是：如果能夠，就盡量努力嘗試；如果不能勉強，就不要勉強。
我先從後者講起。
如果不能勉強，就不要勉強
Story 有很多種，“user story” 只是其中一種。就連大師 Mike Cohn 在 User Stories Applied 也承認：「產品 backlog 中，有面向客戶的任務，也有技術類的任務。」
事實上，整篇 The Scrum Guide 文件都沒有提及 “user story” 一詞，甚至連 “story” 一詞都沒有。所以 Scrum.org 有一篇文章 “Myth 4: In Scrum, the Product Backlog has to consist out of User Stories” 主張在 backlog 中放入 technical tasks 是完全正常的，大師 Roman Pichler 在 “10 Tips for Writing Good User Stories” 一文也說：
User stories are not good for capturing technical requirements. If you need to describe what an architectural element like a component or service should do, then write technical stories or—which is my preference—use a modeling language like UML.
簡言之，如果將它轉寫成 user 視角的 story 真的有困難，那麼，不一定非得死守著 “user story” 這種視角。
如果能夠，就盡量努力嘗試
不過，如果你堅持用 “user” 視角來寫 user story，會有更大的收穫。
這是有根據的。
從企業管理觀點來看，彼得．杜拉克在 The Practice of Management 開宗明義提到：「關於企業的目的，只有一個正確而有效的定義：『創造顧客』(create and keep a customer)。企業是什麼，是由顧客來決定的。」
從敏捷觀點來看，User Story Mapping 提到：「我們要量測的是你建造的東西對人們達成目標的方式產生什麼影響。先針對具體的商業目標、客戶和使用者，然後是他們的目標排定優先順序，最後才針對功能。你的任務不是實現需求，而是改變世界。」
綜上所述，如果你能夠盡量以 “user” 視角來審視這些 story 對於他們達成目標的方式產生什麼影響，相較於僅以單一視角（獲利？利潤？）魯莽地提出需求、設計功能，你會有更周全的思考、更多樣的替代選項。
上週有上過 Hans【產品數據分析與關鍵指標設計】課程的同仁，不妨回想一下老師提醒的「從商業與用戶的角度去做解讀」心法。沒上過的，請在我的 Agile Workshop 玩一場 Impact Mapping 變形版，就會知道了。
有了這種觀念，再讀大師 Mike Cohn 在 User Stories Applied 所主張的「切蛋糕」口訣，就順理成章了：
優秀用戶故事準則：每個故事都提供某種程度的完整 end-to-end 功能，稱之為「切蛋糕」(slicing the cake)。儘管不十分完美，即使只提供部分功能，但只要發布的功能可以跑，就可以放心地把應用程式發布給用戶使用。
該怎麼改寫？
理論說完了，回到現實：一開頭列的兩個 autocomplete 任務，要怎麼轉寫成 user story？
⓵ Autocomplete 要能承受 100 rps。
先以工程角度來評估這項 non-functional requirement (NFR)。如果並不難實現，那麼，就不必特別為它另寫一張獨立的 story，直接將它填寫到正常 story 裡面的「驗收條件」一欄即可。
如果仍待進一步評估，那就用一張 “As a service owner, I want to make sure that…” 這種風格的 user story 去陳述，或者乾脆撇開形式，直接用 technical story 去陳述這項純工程純技術的任務即可，不必役於物。
⓶ Autocomplete 要優先置入廣告關鍵字。
我們可以試著用一些 power questions 來輔助思考。
譬如說，將彼得．杜拉克的名言「企業是什麼，是由顧客來決定的」改編一下，請試著回答：「在顧客眼中，這功能是什麼？」
- As a search service user, I want to see keyword suggestions prioritized by advertising spending when I use the autocomplete feature so that I can… {achieve what?}
萬一寫到這裡就寫不下去了，那麼，此刻，或許該暫停一下，用 User Story Mapping 的名言思考一下：「你建造的東西，對人們達成目標的方式產生什麼影響？」
- As a search service user, I want to see keyword suggestions prioritized by advertising spending when I use the autocomplete feature so that I can… {get an awesome impact or… awful impact?}
萬一又寫不下去了，那麼，請改用 Impact Mapping 的角度去反思：這功能若實現了，誰會是這功能的受益者，以及⋯⋯潛在的受害者？
-
As a buyers of digital advertising inventory, I want to increase ad exposure to users’ autocomplete journey so that …
-
As a search service user, I want to …
一旦嘗試從這幾個 user 視角去改寫 story，你會發現，原本的「Autocomplete 要優先置入廣告關鍵字」任務陳述有多麼粗糙。
你可以嘗試的 Power Questions
限制帶來自由。如有可能，請盡可能嘗試用正統的 User Story 來審視你的任務。
也請盡量試著用一些 power questions 來輔助思考：
- 「在顧客眼中，這功能是什麼？」
- 「你建造的東西，對人們達成目標的方式產生什麼影響？」
- 「是否可以像『切蛋糕』那樣寫用戶故事？」