從 Scrum 到 LeSS -使用者故事(三)

更新於 發佈於 閱讀時間約 17 分鐘

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


0x00 回顧

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

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

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

https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle

https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle

在 Waterfall 方法裡
Scope 是絕對的
因此 Scope 的調整需要經過層層關卡
而 Resources, Time 都是 Estimated
所以專案延遲交付或是加人加班
造成成本的追加是很大機會會發生的
因此專案都會設立應急儲備的資金
讓 PM 在必要時可以使用

而 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 能體驗到什麼樣的服務

raw-image
這是在課堂中 PBR 後的其中一個 Story 的樣貌

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

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

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

raw-image
此為課堂中我們小組寫的 Feature File

而 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 還是不滿意怎麼辦?

raw-image
不可能有真正的完美的騎驢法

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

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

raw-image
不管外人怎麼講 無論改變什麼騎法 驢還是驢 — Feature Still Work

這時候就可以來點音樂
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

raw-image
src: Project Management Stack Exchange

避免 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 的目的更為鮮明
而非只是一張可有可無的小卡片

留言
avatar-img
留言分享你的想法!
avatar-img
Justin Shaw's Salon
2會員
7內容數
Justin Shaw's Salon的其他內容
2023/08/06
簡介如何使用 NGROK 來協助開發與測試
Thumbnail
2023/08/06
簡介如何使用 NGROK 來協助開發與測試
Thumbnail
2023/07/31
由於遇到系統不支援歐洲語系的重音符號或變音符號因此有了這篇文章
Thumbnail
2023/07/31
由於遇到系統不支援歐洲語系的重音符號或變音符號因此有了這篇文章
Thumbnail
2023/07/28
Hosts File 是一種可以取代 DNS 查詢的步驟 直接指定 domain 所指向的 IP 位址 甚至是不存在的 domain 也可以使用 hosts file 來給定 IP 位址
Thumbnail
2023/07/28
Hosts File 是一種可以取代 DNS 查詢的步驟 直接指定 domain 所指向的 IP 位址 甚至是不存在的 domain 也可以使用 hosts file 來給定 IP 位址
Thumbnail
看更多
你可能也想看
Thumbnail
2025 vocus 推出最受矚目的活動之一——《開箱你的美好生活》,我們跟著創作者一起「開箱」各種故事、景點、餐廳、超值好物⋯⋯甚至那些讓人會心一笑的生活小廢物;這次活動不僅送出了許多獎勵,也反映了「內容有價」——創作不只是分享、紀錄,也能用各種不同形式變現、帶來實際收入。
Thumbnail
2025 vocus 推出最受矚目的活動之一——《開箱你的美好生活》,我們跟著創作者一起「開箱」各種故事、景點、餐廳、超值好物⋯⋯甚至那些讓人會心一笑的生活小廢物;這次活動不僅送出了許多獎勵,也反映了「內容有價」——創作不只是分享、紀錄,也能用各種不同形式變現、帶來實際收入。
Thumbnail
嗨!歡迎來到 vocus vocus 方格子是台灣最大的內容創作與知識變現平台,並且計畫持續拓展東南亞等等國際市場。我們致力於打造讓創作者能夠自由發表、累積影響力並獲得實質收益的創作生態圈!「創作至上」是我們的核心價值,我們致力於透過平台功能與服務,賦予創作者更多的可能。 vocus 平台匯聚了
Thumbnail
嗨!歡迎來到 vocus vocus 方格子是台灣最大的內容創作與知識變現平台,並且計畫持續拓展東南亞等等國際市場。我們致力於打造讓創作者能夠自由發表、累積影響力並獲得實質收益的創作生態圈!「創作至上」是我們的核心價值,我們致力於透過平台功能與服務,賦予創作者更多的可能。 vocus 平台匯聚了
Thumbnail
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
在上回提到一些應該要避免的措施,以及時時梳理 product backlog 讓團隊有較好的估算,這回則是作為一位 scrum master,我們該如何自省與發現估算的問題,也是以自我反省的方式完結這個系列。
Thumbnail
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
在上回討論 Scrum 對於估算的精神與常見的估算單位,這回就來討論一些應該避免的事項,讓團隊能有更好的估算,下回則是過去的自省與感想。要讓團隊有較高品質的估算,agile coach 或 scrum master 可以觀察一些徵兆,若有發現盡早排除,免得讓團隊成員有壞習慣或是對估算這件事有陰影。
Thumbnail
老實說,從中文書名無法聯想回原文書是《The Elements of Scrum》,雖然書名翻譯沒有太離譜(和內容無關之類的),但總覺得貼近原意會好一點。『Scrum團隊週記』這一章,整個讀完,其實就差不多可以了解Scrum的大部分,所以,若要讀這本書,又沒有太多時間,就先看這一章吧!
Thumbnail
老實說,從中文書名無法聯想回原文書是《The Elements of Scrum》,雖然書名翻譯沒有太離譜(和內容無關之類的),但總覺得貼近原意會好一點。『Scrum團隊週記』這一章,整個讀完,其實就差不多可以了解Scrum的大部分,所以,若要讀這本書,又沒有太多時間,就先看這一章吧!
Thumbnail
上一篇文章我們提到傳統的瀑布式專案管理的方法,這次我們來說說敏捷式方法,還有其特性,以及在 Notion 中應該如何應用。
Thumbnail
上一篇文章我們提到傳統的瀑布式專案管理的方法,這次我們來說說敏捷式方法,還有其特性,以及在 Notion 中應該如何應用。
Thumbnail
講完了 Story 的拆解 其中提到了 Scope 那麼 Scope 是什麼呢? 以及伴隨著 Scope  很常聽到的 Acceptance Criteria (AC) 又扮演了什麼樣的角色? 0x00 回顧 在系列文章中的第一篇 From Scrum to LeSS — Roles
Thumbnail
講完了 Story 的拆解 其中提到了 Scope 那麼 Scope 是什麼呢? 以及伴隨著 Scope  很常聽到的 Acceptance Criteria (AC) 又扮演了什麼樣的角色? 0x00 回顧 在系列文章中的第一篇 From Scrum to LeSS — Roles
Thumbnail
當 Story 被確定下來之後 要如何切割 Story  讓他們可以在 Sprint 期間能 Done 過去經驗我們都知道 當 Story 太大的時候要拆小 但問題就來了 小要小到多小 有可能小到 Task 嗎?
Thumbnail
當 Story 被確定下來之後 要如何切割 Story  讓他們可以在 Sprint 期間能 Done 過去經驗我們都知道 當 Story 太大的時候要拆小 但問題就來了 小要小到多小 有可能小到 Task 嗎?
Thumbnail
最近上完了一門 LeSS in Action 的課程 雖然在 Scrum Team 少說也四五年了 這期間也考過了 CSM, PMP 認證 但這次的課程後對 Scrum 又有了新的認識 同時也回顧一下自己在執行了將近五年的 Scrum 開發經驗
Thumbnail
最近上完了一門 LeSS in Action 的課程 雖然在 Scrum Team 少說也四五年了 這期間也考過了 CSM, PMP 認證 但這次的課程後對 Scrum 又有了新的認識 同時也回顧一下自己在執行了將近五年的 Scrum 開發經驗
Thumbnail
之前,我討論了「敏捷需求」的概念,這個概念被埋入 Nokia 測試(Nokia Test)中。敏捷需求沒有被普遍認同的定義,所以我現在用一個更好說明的標準概念來談。對於許多應用程式來講,特別是網路應用程式,一個故事(Story)只需要...
Thumbnail
之前,我討論了「敏捷需求」的概念,這個概念被埋入 Nokia 測試(Nokia Test)中。敏捷需求沒有被普遍認同的定義,所以我現在用一個更好說明的標準概念來談。對於許多應用程式來講,特別是網路應用程式,一個故事(Story)只需要...
Thumbnail
當我們對敏捷團隊有一些概念後,我們還需要了解在敏捷開發中重要的幾個事件,以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。
Thumbnail
當我們對敏捷團隊有一些概念後,我們還需要了解在敏捷開發中重要的幾個事件,以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。
Thumbnail
連續三十天用三個問題記錄每天的生活 1.今天讓我很有收穫的是什麼書/畫/音樂/視頻? 2.今天讓我幸福/感動/痛苦/恐懼的人/事/物是什麼? 3.如果用一個句子描述今天的我會是什麼?
Thumbnail
連續三十天用三個問題記錄每天的生活 1.今天讓我很有收穫的是什麼書/畫/音樂/視頻? 2.今天讓我幸福/感動/痛苦/恐懼的人/事/物是什麼? 3.如果用一個句子描述今天的我會是什麼?
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News