同事面對看板上面的 user story 卡片,提出一個疑問:

現在愈來愈像是把 spec 或要做的事硬寫成 story。但 story 失去本意的話,好像也不用寫 story~~直接寫成待辨事項,是不是對大家來說更清楚?
現在有點是要寫成待辨事項的 story 吶~~我覺得怪怪的

這問題,其實還可再細分成三件事:

  1. User story 的 "user" 是什麼?
  2. User story 的敘事句,需要有固定格式嗎?
  3. User story 的 "story" 是什麼?

以下就來一一探討。



User story 的 "user" 是什麼?

以純粹論者角度來說,"user" 越接近關鍵的利害關係人,尤其是真實的終端用戶,是最有威力的。所以,如果能夠以 lean canvas 裡的 "customer segments" 及 "channels" 為第一人稱來詮釋,或是以 impact mapping 裡的 "actors" 為第一人稱來詮釋,是最正統的。

所以,大師 Mike Cohn 在 User Stories Applied 書中特別建議,先以 design thinking 之類的方式初步界定出 user role 及 persona,再談 user story 書寫。Gojko Adzic 在 Impact Mapping 書中也建議,user story 的 "user" 層面,要真正對應到 impact map 的 "actor",才不會只是偽裝的待辦事項:

Impact maps help to keep user stories honest --- each story needs to fit somewhere on the map.

網路上也有一些相關的 "user" 建議文章:

當然啦,如果不要那麼的純粹論者,我們可以不必 100% 執著於這種 "user" 角度。像 User Story Mapping 這本書就舉了一個例子,用所謂 "risk story" 來凸顯計畫外工作 (unplanned work) 的不確定性風險。

就連在這領域已經是非常正統的經典著作,都如此說了。我們應該要知道定睛在 "user" 的原因,以及在什麼情況下不墨守成規的理由。

以下文章,對於這類「非使用者視角」的 story,提供一些參考依據:



User story 的敘事句,需要有固定格式嗎?

雖然我在〈咬文嚼字的必要性〉文中認為輔助句型是有幫助的,但我仍要提醒:我們應該要知道定睛在建議句型的原因,以及在什麼情況下不墨守成規的理由。否則,就像 Template Zombies 那樣:

Template Zombie: The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.

事實上,大師 Mike Cohn 在 User Stories Applied 書中,並未使用或建議任何句型,只是很樸素的寫下:

  • Users can do a basic simple search that searches for a word or phrase in both the author and title fields.
  • Users can put books into a "shopping cart" and buy them when they're done shopping.
  • Users, esp non-sailing, gift buyers, can search for a wish list based on its owner's name and state.
  • Repeat customers must be able to find one book and complete an order in less than 90 seconds.
  • Only properly authenticated users can view reports.
  • The site always tells a shopper what the last 3(?) items she viewed are and provides links back to them. (This works even between sessions.)

可是,請仔細檢視,這些是否符合 user story 的 INVEST 原則

Kent J. McDonald 在 Beyond Requirements 第七章,回顧他在製作 Agile2013 大會的投稿系統時,也沒有使用經典的句型:

Note that our story map did not use the familiar “As a . . . I want . . . so that . . .” structure so common to user stories. Instead, we used simple titles such as “Add session proposal,” “Edit review,” and so on.

Even though we did not use the traditional format, we tended to stick with the generally accepted good characteristics of user stories, normally described as INVEST. We kept the stories as small, discrete packets of valuable functionality. Each user story was backed up with examples, and eventually automated acceptance tests, to ensure that the functionality created from them worked as it was supposed to.

Again, we were able to work in this way because we had a great deal of trust among team members, and we all were pretty much on the same page when it came to what we were trying to do.

所以,像 User Story Mapping 這本書,甚至只建議用最簡單的格式,並大量留白:

Simple title:

Who:

What:

Why:

所以,句型或格式只是輔助,重點是 INVEST 原則。

就像《琴之森》說的:



User story 的 "story" 是什麼?

很多人認為,user story 之所以稱為 "user story",就是要在卡片上書寫關於特定 "user" 的一段 "story"。

不過,過於糾結在 "story" 的書面文本,是搞錯了本質。

對於這一點,我認為 User Story Mapping 這本書講得很深刻:

Stories get their name from how they're supposed to be used, not from what you're trying to write down.

也就是說,user story 的 "story" 本質,不在於 "story" 的書面文本,不在於寫下來的有多縝密完備,而在於以它為媒介/觸媒,所進行的敘事過程 (story telling),也就是 3C 中的 "conversation"。

If you're not getting together to have rich discussions about your stories, then you're not really using stories.



所以,回到文章最前面的問題,你覺得,問題的本質在哪裡呢?


PS. 感謝柯仁傑提供 story card 的緣起歷史:A story card is a promise for a conversation.