談談Backlog梳理活動

剛開始嘗試Scrum的團隊，每每都會碰到一個問題，那就是Sprint計劃會議的開會時間過長。筆者就曾經見過這樣一種狀況：爲期兩週的衝刺，Sprint計劃會議足足開了一成天，白天開不完，晚上加班接着開。
那麼爲何會出現這種狀況呢？時間都主要消耗在哪裏？經過觀察，筆者發現大部分時間都消耗在對用戶故事的討論上，具體來講就是對用戶故事的業務、界面和交互，以及技術實現方案和測試要點的討論。

在業界談起Scrum時，每每都只會提到「343」，即——3個角色、4個活動和3個產物。可是在實踐中，咱們發現還須要引入另一個活動，那就是Backlog梳理活動。若是沒有引入Backlog梳理活動，那麼Sprint計劃會議每每會嚴重超時，而在引入Backlog梳理活動，Sprint計劃會議每每可以控制在時間盒內結束。

什麼是Backlog梳理活動？
Backlog梳理活動，是在下個衝刺開始前，對可能要歸入到衝刺中的故事進行細化、估算和優先級排序的活動。

誰參與Backlog梳理活動？
PO、SM和團隊都應當參與，其中SM是活動的組織者。

何時開展Backlog梳理活動？
在本衝刺中要完成下個衝刺的Backlog梳理，確保下個衝刺的故事在Sprint計劃會議啓動前要符合INVEST原則。
在實踐中，咱們發現Backlog梳理過程當中每每會碰到沒法當場肯定的問題，因此不能期望經過一次開會來完成Backlog梳理，更好的作法是天天都花一些時間來作Backlog梳理。

如何開展Backlog梳理活動？
在實踐中，咱們整理出Backlog梳理五步法，具體以下：

① PO和團隊一塊兒討論用戶故事的背景、業務目標、用戶角色、用戶場景、業務流程、業務規則，保證團隊理解充分而且無異議。

② PO和團隊一塊兒討論界面和交互流程，畫出低保真和交互流。

③ PO和團隊討論用戶故事的測試要點、技術實現方案、可能存在的技術風險，必須輸出測試要點（即驗收標準），測試要點形式不限（建議直接寫在故事卡的背面，這樣方便查看）。

• 其中能夠分爲如下三個過程：

1）PO與一個資深測試人員討論和整理出測試要點。
2）PO與整個開發團隊交流用戶故事的測試要點。
3）開發團隊討論初步技術實現方案、技術風險。

• 其中的注意事項：

1）要先準備好測試要點，避免一羣人坐在一塊兒從0開始整理。
2）討論初步技術實現方案的目的是爲了作估算、識別技術依賴以及技術風險，詳細的技術實現方案應該留到衝刺開發時再討論。

④ 團隊估算出用戶故事的規模（故事點數），對於過大的用戶故事要拆分紅小故事。

• 其中包括如下過程：

1）PO先與SM，對用戶故事作初步估算以及拆分，以便進行下一個發佈版本的衝刺規劃。
2）對於下一個衝刺要用的故事，SM組織開發人員估算出開發規模，組織測試人員估算出測試規模，再集中整合。

• 其中的注意事項：

1）爲了作發佈版本的衝刺規劃，須要進行初始估算，這個活動不須要整個開發團隊都參與，只須要少數核心人員參與。

⑤ PO對用戶故事排優先級。（在產品Backlog中創建用戶故事卡，順序即優先級）

• 排優先級只須要PO決定便可，不須要其餘人蔘與。
• 之因此放在第⑤步，是由於排優先級時要考慮用戶故事的規模、技術上的依賴關係和技術風險。

關於做者：李潔（Jerry Li） ，Scrum中文網資深敏捷顧問 

本文轉載自：敏捷工具Leangoo.com