(改寫自公司內部 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?

  1. Autocomplete 要能承受 100 rps。
  2. 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 對於他們達成目標的方式產生什麼影響,相較於僅以單一視角(獲利?利潤?)魯莽地提出需求、設計功能,你會有更周全的思考、更多樣的替代選項。

From: The Practice of Management

From: The Practice of Management

上週有上過 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 來輔助思考:

  • 「在顧客眼中,這功能是什麼?」
  • 「你建造的東西,對人們達成目標的方式產生什麼影響?」
  • 「是否可以像『切蛋糕』那樣寫用戶故事?」