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

上一篇
講完了 Story 的拆解
其中提到了 Scope 那麼 Scope 是什麼呢？
以及伴隨著 Scope 
很常聽到的 Acceptance Criteria (AC)
又扮演了什麼樣的角色？

0x00 回顧

在系列文章中的第一篇
從 Scrum 到 LeSS — 角色
裡面有提到
PO 作為 Police Officer 的角色
要控管 Story 要交付的 Scope 有哪些
不應該讓需求貢獻者或團隊增加 Scope

而系列文章的第三篇
從 Scrum 到 LeSS －使用者故事（二）
提到了可以採用
識別 Scope 是 Increment 或 Iteration
來作為 MVP -> PMF 的界線

那麼 Scope 是什麼？
我們來看一下軟體開發的鐵三角

而 Agile 方法裡
資源固定（Teams）、時間固定（Sprint）
因此成本固定
Scope 則是 Estimated 而來
所以 Scope 的調整以 Agile 來說是必然的
甚至可以說
Sprint 期間 Story / Scope 無法全部被 finished
理應也是預期的
因此相較於 PM 有應急儲備資金
PO 的最重要的任務就是在
有限資源（開發團隊 ＆ 開發團隊的產能）
有限時間（n 個 sprint）
的前提下透過調整 Scope 以及 Priority 
來讓產品可以儘早的帶來商業價值

雖然 Scrum 中 Sprint 固定時長
但到底要幾個 PSPI
才能完成 Shippable Product
是 PO 的權力

倘若 PO 不斷地去追求完成所有 Scope 才上線
而不是透過先有增量 increment
再透過迭代 iteration 持續改善
那麼 Sprint（衝刺）
就變成 Marathon（馬拉松）
Review 變成 Check Point
到最後就就是無限迭代
無法預期何時才能上線
無限拉高成本

0x01 Split Scope

簡單做個假設

兩個團隊在做開發各別 7 人
每人月薪 5 萬
一個 sprint 兩週
可以算出一個 sprint 就要支薪
5 * 7 * 2 / 2 = 35 萬
接著從公司的角度包含其他非薪金支出
約 1.5 倍來估算
35 * 1.5 = 52.5 萬
每個 Sprint 公司就要支出至少 52.5 萬成本

由此可知
如果某個 User Story 
原訂需要兩個 Sprint （四週）才能完成
那麼公司就要支出至少 100 萬的成本
而 PO 每延遲一個 Sprint 交付
就是支出約 50 萬

此時就需要回過頭來看
這個 User Story 是不是真的有那麼高價值
或是這個 User Story 
是否可以減少 Scope 然後提早上線
確認真的有帶來正向影響
再繼續為它開發

正向影響
可以從最基本的 ROI 
(Return of Investment)
或是日/月活躍用戶提升百分比
或是新用戶提升多少
或是客戶留存率提升多少
也有可能是客訴下降的百分比
等等預期達到的指標

若沒有設立這些指標
就無法知道投入這些成本到底為了什麼
也不知道下次可以改善什麼

回過頭來
所以 Scope 是什麼？
從上面的敘述應該可以看出
Scope 對 Story 而言
就是會影響交付 Story 時間成本的工作量

舉例來說
某個數據顯示
從加入購物車到結帳的轉換率有點低
根據 BA 的研究
也許是因為關閉網頁之後再回來時
購物車被清空導致
因此希望能做到
User 下次回訪時
能看到之前已經加入購物車的項目
進而提升轉換率 X% 因此有了以下 Story

As a Customer
I want the cart keep my added item
So that when I came back I don’t need to add it again

從這個 story 來看
就會有兩個明顯的 Scope 要做

1. 保存購物車紀錄
2. 當商品已經沒有的時候要提示使用者，並移除該項目

但團隊在 SP2 的時候發現
保存購物車紀錄在現行的架構上有一定的難度與工作量要做
此時可能就可以將 1. 拆成兩個 Scope
1–1. 保存紀錄在 browser local storage
1–2. 保存紀錄在 DB

這時對交付可能會有些影響

a. 使用者若換不同瀏覽器或裝置一樣沒有紀錄
b. 使用者使用無痕模式也沒有紀錄

這時候 PO 就有幾種選擇
1.「完美版本」
繼續增加交付成本、以及延後交付時間
以達到原本規劃的所有內容
2.「有部分情境能滿足就先開出去觀察」
先開一部分的客戶做 A/B test
並且觀察是否有如預期的將轉換率提升 x%
再繼續評估是否要繼續開發此功能
若效果不如預期那也沒有繼續開發的必要
應找出其他提升轉換率的解決方案

那麼怎樣可以不讓時間成本無限上綱呢？
由於 PSPI 不一定是可以直接交付的東西
Shippable Product 才是
因此為設立 Milestone
 （or 大家比較不喜歡聽到的 deadline）
是一個可行的方法

因為在某個時間點所累積起來的 PSPI 
被迫要能達到 Milestone
這樣一來才能在
有限資源、有限時間的狀態下
去因應 Scope 的非預期變化
並且在該上線的時間點上線
提升產品競爭力

0x02 From Scope to Scenario

不知道看到上述的例子時
各位有沒有心裡想著
為什麼不乾脆依照工作拆分成

1. 完成 UI 
2. 存入 DB

這兩個 Scope 就好
同樣也能達到拆分的效果

在前一篇我們提到
拆 Story 的時候應該要遵循 3V 的原則
拆 Scope 也是同樣的道理
原因還是在於
每一個 Scope 被 Done 的時候
PO 是否有機會選擇 release
因此相較於 Scope

我更喜歡先從 Scenario
去思考怎麼做到降低工作量的同時
還是能滿足一定程度上的情境

以上述的例子來說
也許存在 Local Storage 就已經能滿足 Y% 的 User
因此這 Y% 的 User 就能在新的服務上得到滿足

如果當次的 Sprint 真的只能完成 UI
那麼其實是沒有太大價值的
因為如果 PO 想要看到 UI 長怎樣
去看 designer 的圖就可以
因此完成 UI 只是證明了
「噢！我們能做出跟設計稿一模一樣的 UI」

反過來說
如果 PO 真的只想 release 一個美美的畫面
那為什麼不乾脆把 designer 的稿
輸出 html 丟到網頁上呢？

0x03 Contract Game

Acceptance Criteria (AC)
本質上應該是用來補充 Scenario / Scope 的細節注意事項
因此有沒有 AC 理應都不該做錯 Scenario / Scope

但根據觀察
無情境的 AC 到後來很有可能把 Scrum Team 導向
PO vs. Dev Teams 的 Contract Game

為什麼會如此呢？

其實就是「不確定性」
原本 Agile 就是應該擁抱「不確定性」
承認其實所謂的需求本來就不可能講清楚

俗話說世界上最難的兩件事
1. 把別人口袋裡的錢放到自己的口袋
2. 把自己腦袋裡的想法放到別人的腦袋

當 PO, Teams 其中一方無法擁抱不確定性
那麼就會開始有不安全感

通常比較常見的狀況就是
Teams 交付成果
也完成 DoD 了
Scenario 也是正常的
但 PO 就是對交付出來的東西不滿意
覺得缺少了他想要看到的東西
接著就會有
「怎麼我沒講就沒做」
開始責備團隊

到下一次的 Sprint 開始增加 AC
甚至可能不是 PO 要求要增加
也許團隊為了不想被責備
就自己要求 PO 要講得更詳細
然後簽名畫押

因此就會玩起甲方乙方的合約遊戲
把無情境的 AC 當作 Spec 來寫
時間久了
Story 其實有跟沒有一樣
甚至會發現
有些 Story 是

As a …
I want …

先不說開頭沒有 In order to
就連 So that 都不見了
更甚至有時會看到

As a PO
I want a OOO feature

這種赤裸裸的 request
但沒人在乎 Story 的合理性了

因為大家只在乎
「名為 AC 實為 Spec」的 AC
由於沒有人想為無法如期上線背鍋

Agile 的 Scope 本來就是 Estimated
因此 Sprint 無法將所有東西 Finish
本來就是理所當然

回到上面的情境
在 Scenario OK, DoD OK 的狀態下
PO 若對交付成果不滿意可以怎麼做？

別忘了 Scrum 本來就是仰賴 Sprint 的循環來持續改善
若這個 Scenario 已經可以為產品提供增量
那麼就是評估距離 Milestone 還有幾個週期
而下一個週期要不要為這個增量做迭代
讓他更好或是繼續往下一個 Scenario 前進
儘早的累積所有的 PSPI 來達到 Shippable Product 的程度
還有餘力再繼續迭代

從測試的角度來看一些過度強調精細的 AC
某個 banner 的高度多高我們會去寫測試嗎？
如果不寫測試
不會去保護他
那麼對於這麼精準的要求
不能容許有誤差
並且要調整到和設計稿一模一樣的意義其實不大
因為也許過兩三個 sprint 之後就算他歪了 1 pixel 也沒人知道
既使發現了
是不是會開 Ticket 去修？
從結果回過頭來看
就會發現在當下的這些過度要求的「條款」
不但對 User 產生不了價值
同時也墊高了交付成本

本來 Scrum Team（PO & Dev Teams）
應該是站在同一條船上的 Team
不斷向前衝並且共同成長
在有限條件下
（Fixed Release Date, Team Technical Skill …）
為產品帶來價值的最大化

畢竟東西到底是不是完美
或是倒底能不能讓用戶滿意
也並不是誰說了就一定是「正確」的
一個產品要服務的客戶眾多
PO 也只是眾人之一
用最少的成本完成 PMF
趁早的上線搜集數據搜集回饋
才有可能找出眾多 User 中相對完美的版本
有沒有必要在已經滿足 Scenario 的情形下
持續的追求 PO 自己心中的 100% 完美版本
其實是有待商榷的

若 Scrum Team
陷入合約遊戲
那麼這艘船無法向前衝
因為這種文化是毒藥
大家只追求不要背鍋
而不是把鍋拿起來炒一鍋好菜
因此把失誤推給

AC 沒有寫!!!

是最輕鬆的事情
也很容易上癮的事情

0x04 A-TDD

那麼要怎麼避免上述的方式呢
從人去解決總是比較困難的
如果團隊已經陷入 Contract Game
不仿考慮大家拉開一點距離
換掉工具
不要再繼續寫 Spec. (無情境 AC) 了
嘗試改為 A-TDD 吧！

Acceptance Test-Driven Development
驗收測試驅動開發

先思考這個 Story 希望提供 User 什麼樣的 Behaviour Change
把這些關鍵實例寫下來

在 LeSS in Action 的課程中
講師用了這樣的模板
來促進大家在 PBR 的討論

General:
Scope:
Assumptions:
Keys Examples:

General:
可以是很粗淺的 Idea 
或是想要解決的問題
也可以是已經稍微有點樣子的 User Story

Scope:
即較大範圍的工作量（如上面提及的）
當然這些工作量是有可能在 SP2 之後再去做裁減

Assumptions:
當大家在討論過程中
有疑惑但可能 PO 或需求貢獻者正在別組的時候先記錄下來
經過不斷的溝通與釐清
將這些假設確立出明確的答案

Keys Examples:
關鍵實例，把確認的 Scenario 寫下來
用以說明這個 Idea 是期望 User 能體驗到什麼樣的服務

可以看到在過程中大家會盡量的去描述
甚至做些簡單的 Mock UI 確認使用情境
而不是一條條沒有生命的 AC

有了這些實例之後
怎麼驅動呢？

我們可以嘗試將他規格化
e.g. Given When Then
接著套用一些工具如 Cucumber 來文件化

而 Sprint Review 的階段
Teams 也不用再為了 Demo 花時間準備
直接打開來執行測試
就可以知道這個 Story 已經完成了多少

Show tests in Sprint Review
In a Sprint Review, the team demonstrates visible progress to the Product Owner by showing the output of the iteration.
We worked with some groups that defined the demo steps during the Sprint planning. The team would spend an inordinate amount of time in demo preparation. A complete waste.
During Sprint Planning, an alternative is to define the examples that need to pass and show the progress by using these tests in the Sprint Review.
ref: Acceptance Testing

再次回到上面的問題
如果 Sprint Review 後 
DoD 完成了
Scenario 也透過展示自動化測試 Pass
但 PO 還是不滿意怎麼辦？

那就把希望繼續改善的部分
進入下一個 Sprint 迭代囉！
只要 Scenario 不變
這個 Feature File 也不需要更改
下一個週期的 Sprint 結束後
一樣的在 Sprint Review 重新執行一次
就能證明系統想要提供的功能
都還是好端端的

畢竟要不要 release 是 PO 的權責
團隊沒辦法直接干涉
但至少作為開發團隊的成員
我們可以很有信心的說
隨時 Release 都沒問題

這時候就可以來點音樂
I’m ready for release
I’m ready for you
I’m standing right here
I’m waiting for you…
I’m ready for release
I’m ready for you
I’m standing right here
I’m waiting for you…

0x05 Living Documentation System

將關鍵實例從 Story 萃取出來的好處
除了縮短驗收時間
確保功能沒有損壞之外

同時我們還獲得了一份活的說明文件系統
如果今天有個新人需要做新人訓練
甚至可以直接請他看這些文件
理應就能了解這個應用到底提供哪些服務

0x06 小結

擁抱執行 Scrum 時對於 Scope 的不確定性

避免無限修改的發生
設立一個 Milestone 作為 release date 
在那個時間點就是 release 
而在 Sprint 的過程中不斷的去因應變化做調整
不斷的 iterative & incremental
而非完成所有 spec 才 release

避免 Contract Game

厲害的 PO
是能使用手邊的有限資源
可能是人數不多
可能是技能不足
可能是時間不夠
的這些狀態下
照樣交付價值到商業環境

不應該把非客觀的「不滿意」
將團隊推向 Contract Game
Scrum Team 理應是學習型組織
大家是共同的學習成長
而非互相卸責

如果一直追求的是 100% Spec
大家還是喜歡 Contract Game
甲乙方簽名畫押的方式
那麼組織應該思考一下
也許需要的不是 Agile 而是 Waterfall

用 Living Documentation System 的方式

取代無情境的 AC 來讓使用情境更加的明確
也能更加的 focus 在交付的 feature
而非一條條的規格
同時也能確保在後續的迭代不會改壞
畢竟 AC 通常都是交付了之後就不再去維護的東西
但做產品需要維護的就是已經在線上的 Feature

因此 Living Document 的好處包含
某天需要重新打造系統的時候
不會遺失本來就有的 feature
因為在商業模式沒有改變的狀態下
就算整個系統重寫
這些 feature 也應該還要持續提供給 User

0xFF 參考資料

文章：Specification by Example
書籍：《Specification by Example 中文版：團隊如何交付正確的軟體》

沒想到光是 Story 就寫了三篇 …
希望這些文章能讓 Story 的目的更為鮮明
而非只是一張可有可無的小卡片