用戶故事與相對估算 • 技術領導與產品思維

讀完這章你要能回答：一則好的用戶故事長什麼樣？為什麼 story point 不是工時？什麼是「固定時間、彈性範圍」的發布規劃？

把需求拆成可交付的小塊，並用團隊自己的節奏來估算與發布。

用戶故事（User Story）#

產品經理基礎介紹的 product backlog，裡頭裝的就是一則則用戶故事。用戶故事不是規格書，而是「一段待展開的對話」。

用戶故事的經典格式：
作為（As a）某類使用者， 我想要（I want）做某件事，以便（so that）達成某個目的。
重點在最後一句「以便」——它說明了為什麼，連結回使用者真正想完成的「工作」。少了它，故事就退化成沒有脈絡的功能條目。

範例：

作為一個通勤的上班族，我想要 App 記住我上次聽到哪，以便被打斷後能直接續聽，不用重找。

一則值得放進 backlog 的故事，應該通過 INVEST 檢查。

故事太大、估不動，通常代表它還沒被理解清楚。這時不要硬估，而是回到梳理流程把它拆小。

Story point 是相對大小，不是工時。一個 3 點的故事，意思是「大約是 1 點故事的三倍工作量」，而不是「要花 3 小時／3 天」。
為什麼不用工時？因為人類擅長比較大小（這顆比那顆大），卻不擅長預估絕對時間。用相對點數，能避開「到底幾小時」的無謂爭論，也讓估算更穩定。

常見做法是用費氏數列（1、2、3、5、8、13…）當點數刻度——數字越大、間隔越大，反映「越大的東西越估不準」。

1. 主持人朗讀一則用戶故事，團隊澄清疑問
2. 每人手上有一組點數卡（1, 2, 3, 5, 8, 13...）
3. 同時亮牌（避免互相影響、錨定）
4. 若估值分歧大，最高與最低的人各說理由
5. 重新亮牌，直到收斂到共識
6. 記下這則故事的點數，進入下一則

同時亮牌是關鍵。先聽到資深工程師喊「2 點」，其他人就會不自覺跟著喊——這就失去了集體判斷的價值。

「速度」= 團隊一個 sprint 平均完成的點數，用來預測「這些 backlog 大概要幾個 sprint」。

速度至少要累積 5 個 sprint 以上才有參考價值。前幾個 sprint 團隊還在磨合、估算還不穩，拿來預測或拿來比較不同團隊，都會誤導。速度是團隊對內的規劃工具，不是對外的績效指標。

傳統專案常想「時間、範圍、品質」三者全鎖死，結果往往三者皆崩。敏捷的發布規劃改成：

鎖死（不退讓）：
├── 時間：發布日期固定
└── 品質：達不到 Definition of Done 不算完成

彈性（可調整）：
└── 範圍：時間到了，就發出「已完成的最高優先級故事」

換句話說，當進度吃緊，砍範圍而不是砍品質或延期。因為 backlog 已排好優先級，砍掉的永遠是最不重要的那些。

Definition of Done（DoD）是團隊對「什麼叫做完」的共同約定。沒有 DoD，「我做完了」這句話人人定義不同——有人指寫完程式，有人指上線可用。

一份典型的 DoD 清單：

DoD 對所有故事一體適用，是「品質底線」；驗收標準則是逐則故事不同的「這則故事要對的事」。兩者搭配，才能讓「固定品質、彈性範圍」真正落地。