從 Scrum 到 LeSS －使用者故事（一）

前一篇的 Roles 在介紹的同時
提到了 Potentially Shippable Product Increment
PSPI 即是 Scrum 中的 3 Artifacts 之一

而這三個 Artifact 分別為
- Product Backlog
- Sprint Backlog
- Potentially Shippable Product Increment

如果我們細看下去
會發現其實它們就是 Story 的流動
從一開始 Story 的出生
就會被放進 Product Backlog
經過漫長的等待
終於在某次的 Sprint 中被提到 Sprint Backlog
接著透過獅子🦁及猿猴🦍們的努力
將 Coffin 轉換成 Code
Story 終於蛻變成了 Potentially Shippable Product Increment

因此 Story 寫得好不好
就決定了小從 Sprint 大至 Product 的好壞

所以這篇會著重在 Story 怎麼寫
它應該包含哪些要素

0x00 回顧

Story 怎麼寫才對呢？
通常 As a User … 開頭
但 User 到底是誰也會有爭議
e.g. As a PO … 
這種寫法到底有沒有問題？

有時候 Story 寫起來就是怪怪的
但不知道哪裡怪怪的
總之好像看不出來 Value 在哪裡？
而 PO 總是說 Value 就是大家賺大錢啊！

如果有以上問題
那麼我們就可以從一個好的 Story 
要怎麼誕生開始說起

0x01 Insight

一個 Story 的誕生無論是為了改進或是創新
理應都是 Manager, Business Analyst, UX Researcher … 等等
洞見了某些需求尚未被滿足
或是透過數據研究、使用者經驗分析而來

上面敘述不使用 PO 這個 role
原因在於 PO 著重的是排序在這個階段被產生出來的 Story 做價值排序
若 PO 本身身兼 BA 那麼理應也是透過這樣的流程來梳理 User Stories

但一個靈光一現的想法
要怎麼逐漸描繪出更大的輪廓
可以透過《Impact Mapping》的方法來分析

- Why are we doing this?
- Who will be impacted by it?
- How should our actors’ behaviour change?
- What can we do to support the required impacts?

應該會產出類似的文件

https://www.impactmapping.org/example.html

https://www.jpattonassociates.com/story-mapping-quick-ref/

關於使用者故事對照的其他相關參考資源

Story Mapping Quick Reference
User Stories Quick Reference

到目前為止對於多數 Story 的產出是不會有太大的問題
但根據實務上的經驗
在 Impact Mapping 的時候如果可以加上 When 可能會更好
因為一個 Story 本身的價值也會隨著時間推移而變得沒有價值
能不能站上風口浪尖
抑或是避免需求提早被競品滿足流失客源

另外一點就是 Who 可能會遺漏
在 Impact Mapping, User Story Mapping 時
產出常常都是「能被看見」「能被交付」的
但有一些雖然不需要使用交付出來的產品
但卻會被推出的 Story 受影響對象可能會遺漏
例如：合作夥伴、第三方供應商 …
當 Feature 一上線
結果打到自己人
雖然有機會提升公司收益
但卻影響合作夥伴或是第三方供應商

這些人理應在 Impact Mapping 時
就要被提出
但卻容易遺漏
也許可以用《獲利世代》所用的商業畫布
來協助提早抓出遺漏的部分
也可以讓整個 Story 的價值（$）流動更清晰

https://en.wikipedia.org/wiki/Business_Model_canvas

0x02 Tell Stories, don’t write them

Tell Stories, don’t write them
ref: 《Fifty Quick Ideas To Improve Your User Stories》

當 PBR 的時候
會從 Product Backlog 拿出 Story 
更細節的描述需求
甚至比較規格化的寫成 Story Card

而過去在「寫 Story」 的過程中
常常就是拿著白色小卡敲腦袋
接著像是在玩小學的填空遊戲
As a OOXX
I want AABB
So that XXYYZZ

但 Story 不就是應該能被敘述的故事嗎？
人們從小的時候就喜歡聽故事
尤其好的故事更能讓人印象深刻流傳百世

那麼一個好的 User Story 也應該如此
即便不能流傳百世
至少在完成交付之前
大家都能記得自己要交付的「價值」是什麼
而不會產生太大的落差
但如果大家只記得交付的「Feature」是什麼
那就不是一個很好的 User Story
也會有很大的機會根本解決不了 User 的問題

畢竟 Story 是觸發 PO、需求貢獻者、開發團隊開啟討論的一塊磚而已
若一開始就陷入填字遊戲
反而會阻礙討論
缺少討論的 Story 久了就會開始變得像 Spec
寫了很多的 Feature 但並沒有描述到底解決了什麼問題

Letting go of a template, and trying out different formats, can help to shake up
the discussion. This also helps to prevent fake stories.
ref: Fifty Quick Ideas To Improve Your User Stories

這邊提到 Fake Story
就會讓我想到有些 Story 
雖然自己寫了很多字
但說穿了就像是

As a Player
I want play game
So that I can play game

或是硬塞給 User 的需求但 User 根本不需要
例如：

As a 阿罵
I want 孫子穿多一點
So that 孫子就不會冷

接著就透過 AC 
寫出一堆驗收條件來滿足想做的 Featuer
Story 就只是掛羊頭賣狗肉

現在想起來真想挖洞把自己埋了🕳

0x03 Persona & User Journey

我自己也不是一個很會講故事的人
但想起以前學習 UX 相關課程的時候有學過
Persona（人物誌）
User Journey（使用者旅程）
的方式來描述
但通常來說可能不太需要用到 Persona 
除非是要解決特定類型用戶的痛點

以前 UX 的課程會舉例
要求要把按鈕做大一點
但實際需求根本不是按鈕不夠大
（但有點忘了當時講師的舉例內容了）

這邊用自己的實際經驗當個例子🌰

我過去很常抱怨某 P 家的搜尋功能
總覺得他們的搜尋功能很難用
每次都找不到我要的東西

如果他們有地方讓我客訴
我肯定去抱怨
「你們的搜尋總是找不到我要的東西
M 家都可以找到」

我想應該不止有我覺得 P 家的搜尋功能很差
在這情形之下產品經理聽到這個抱怨
可能就會一聲令下
開 Story 要求「優化搜尋結果」

但優化搜尋結果真的就能解決我的問題嗎？

如果從我自己（簡易版）的 User Journey 來看

我聽到朋友說某個 Z** K** **茶 不錯喝
讓我想要明天就喝看看
所以我就上 P 家網站搜尋
結果顯示了一堆相似但是又不是我想要的
因此我就覺得很搜尋功能很差

過了很久
某天無聊實驗了一下
我終於發現其實不是他的搜尋功能差
實際上 P 家的搜尋可能沒有什麼問題
但當他找不到 100% 吻合的產品時
（其實就是他根本沒上架的商品）
就會列出一堆相似的產品
所以 其實不是搜尋的問題
相對的以「搜尋能力」來說
它似乎還做的比 M 家好
可為什麼我會覺得 M 家搜尋比 P 家好呢？

因為 P 家的搜尋讓我覺得它「假裝有幫我找」

所以回過頭來看這個 User Journey
就會有兩個點可以思考
1. 搜尋結果的呈現是不是不太友善
2. User 想要的東西為什麼沒有

從這兩點來看就可以發想一些解決方案
例如：
1. 就可以改善顯示介面
當沒有 100% 吻合產品時應該有提示
接著把模糊查詢的推薦有明顯區隔

2. 去爬別家網站如果有該商品就直接爬過來顯示出來
接著顯示貨到通知的按鈕
這樣就可以知道有多少 User 期待這項商品
然後發 daily report 給採購去評估接洽

再回頭看前面的抱怨
如果 P 家的產品經理直接拿了 User 抱怨搜尋結果不佳
而忽略了講述 User 實際遇到的情況
搜集足夠的資料
那麼團隊花了很大的力氣去強化搜尋結果
其實還是解決不了我的問題

希望以上的小故事有突顯出
如果一開始就直接定義要用什麼 feature 解決
而少了 user journey 的 story
或是 impact mapping, user story mapping
就很容易花時間花錢做了很厲害的功能卻無法解決用戶問題

0x04 Behaviour Change & System Change

回過頭來看 User Story 的本質
如果一開始 Story 就被 I want X Feature 框住
那就可以邀請需求提供者多描述以下兩種面向

Behaviour Change
當這個 Story 被交付的時候
使用者有什麼行為會改變
當這個改變被描述的時候
理應就會帶出可被量化的指標
例如：funnel conversion rate 的前後差異

而描述 Behaviour Change 的同時
User Journey 也應該會跟著改變
那麼在描述的過程也許就會發現
想要觸發這個改變也許不一定要做 X Featuer
也許 A Feature 也能達到而且可以用更少的改動完成

System Change
有時候一個 Story 的交付可能是為了改善系統
因此使用者行為並沒有改變
此時應該多描述這個系統的改變是為了解決什麼問題
多描述這個會有幾個好處

平時常見的需求可能是
直接被要求 reduce API response time 50%
這類的 Story 除了上述的
As a … I want … So that …
起頭如果可以加上 Instead of 來描述目前系統遇到的問題
這時候在 Story 上也能有更多的討論空間
因為 Instead of 已經描述了從 User 角度面臨的問題
此時的討論就不一定會被侷限在 API Response Time
也許會發現可能根本不是 API Response Time 的問題
可能是網頁上的圖片太多導致第一次開啟太慢
也有可能是使用者當地的網路太慢
需要出一款 Lite 的版本
或者 reduce 50% 的時間
會使得 Story Size 過於龐大
那麼就能多討論 recude 30% 
是不是也能解決 User 遇到的問題
且 Story 的大小也能降低很多

0x05 小結

簡單的總結一下
套用一下課堂講師說的一句話

每個 Story 交付之後
這個世界上應該會有人的生活過得更好

如果 Story 交付了但 User 還是有可能抱怨
那可能就要好好思考一下這個 Story 是不是真的有解決問題

User Story 是從使用者角度出發的故事
使用者在使用系統必然的會有些目的
這些目的使得他們存在著某種角色
因此 Story 不要再用 As a User 開頭
而應該是他的 Role
也不會是 As a PO
因為 Scrum 的定義裡
PO 不會是依賴在產品的 User
他最重要的工作就是 Story 的價值排序
除非今天是要交付一個 Scrum Software
e.g. Jira
那才有可能是 As a PO 的 role 操作系統

多關注在 Business 的討論
而不是 Feature / Spec
以避免交付沒有價值的產品
或是賠錢的產品
因為開發本身就已經投入成本了
如果交付的東西不能帶來價值
那就是賠錢

Story 本身不一定要用什麼 template 來寫
只要是能讓所有人都能理解的方式
就是好的 Story 格式

如果要用
As a … 
I want … 
So that …

可以在開頭多加上
In order to …
或是
Instead of …
這樣更能展現出 User Journey 的感覺

0xFF He did see this, that’s why it’s here

這邊想要引用一小段迪士尼的 Story

I’ll always remember something he said during our 50th when he shared a story about a man at Disneyland Park who asked him, “Isn’t it a shame that Walt Disney couldn’t be here to see this?” and Art said, “He did see this, that’s why it’s here.”
ref: A Moment With Art

一個好的 Story 可以讓大家都看見
因為看見了所以實現了它的價值

大家可以看看自己手上的 Story
你有看見 User 的笑臉了嗎？😃

希望這篇有助於不知道怎麼衡量 Story Value
或是總是苦惱於怎麼照樣照句的朋友