敏捷中班～產品待辦清單精煉會議

11th鐵人賽鐵人賽敏捷開發 agile scrum

文思不藏私

2019-09-20 09:17:22

2372 瀏覽

分享至

常聽到很多人談到『什麼是產品待辦清單精煉會議（Product Backlog Refinement）？』、『到底需不需要產品待辦清單精煉會議（以下用精煉會議表示）？』因此，我收集了一些談『精煉會議』的資料，希望對自己有些幫助。

定義

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.~Scurm Guide

老實說，很多人了看了這段定義後，也是有看沒有懂。可能只是瞭解

『產品待辦清單精煉會議』是一個持續為產品待辦清單增加更多細節、估計及優先順序的作法。
這是一個由『產品負責人』跟『開發團隊』協同合作對『產品待辦清單』的『待辦事項』進行細節討論、檢視、修改的過程。
Scrum 團隊可以決定何時或如何來完成『產品待辦清單精煉會議』，但以不超過開發團隊 10% 以上的產能為限。

以下是我個人的理解。『產品待辦清單』中待辦項目的細節程度不一樣，最優先的項目，其細節應該越多越清晰（又稱為 Story），越長遠的計畫與安排，則細節越小越抽象（又稱為 Epic 或 Theme）。比如說電影票訂票系統，最優先的項目是『訂票』，但『訂票』是一個很大沒細節的項目，如果直接把它進『衝刺計畫會議』（Sprint Planning）是一個很抽象，很花時間討論的項目。因此如果在『衝刺計畫會議』前，能將一些預期帶進下一回『衝刺計畫會議』的項目，透過『使用者故事』（User Story）或『技術調研』（Technical Survey）進行『產品待辦清單精煉會議』。將有助於『衝刺計畫會議』更能聚焦。

個人看法『2 2 2』原則，通常希望『產品待辦清單精煉會議』以一個長度為 2 個星期的 Sprint，一次不要超過 2 小時較佳，除非有重要的考量，不然最好不要超過團隊 1/2 成員都參加。Scrum Guide 中提到不超過 10%，也就是一天，我通常以一天 6 小時算，但如果真的需要整整一天的話，應該分為三次，每次還是不要超過 2 小時。

為什麼？

因此『產品待辦清單精煉會議』在於

『大事化小事』
『模糊變明確』
『未知成已知』

『產品負責人』（Product Owner）理論上，對『產品待辦清單』應該是最瞭解的人，所以他可能隨時都在對『產品待辦清單』上的項目進行精煉動作（分割，合併，新增，刪除，修改）。但對於他無法自行處理，而且優先權很高的項目，他可以選擇帶進『精煉會議』跟開發團隊進行討論。

是不是全部下一個衝刺的項目都需要帶進『精煉會議』呢？我個人是認為不用，優先權（priority） + 時間盒（time-box）才是重點。什麼樣的項目才需要『精煉』呢？很多文章都提到『INVEST』及『SMART』原則，我認為只要是沒達到『INVEST』原則皆可以帶進討論。

何時？

如果是 2-weeks sprint 建議『精煉會議』發生在第一週的尾巴（星期四或星期五），用兩小時的時間討論下一個 sprint 可能會帶進來的產品待辦事項。為什麼呢？因為『大事化小事』、『模糊變明確』、『未知成已知』可能需要花一些時間進行技術調研，如果發生在第二週接近 review 的時間，一來技術調研的時間可能不一定足夠，二來通常接近 review 可能需要先把要 review 的 story 確定其 DoD（Defination of Done）是否達成，不一定有足夠的時間可以做 refinement 討論。

很多人都一直誤認為『衝刺計畫會議』是 Scrum 中的第一個會議，其實正卻的說法應該是『產品待辦清單精煉會議』才是 Scrum 中的第一個會議。因為唯有經過『產品待辦清單精煉會議』討論後，夠清晰、夠小、已估計的工作項目才會被帶入『衝刺計畫會議』討論。

何人？

當然產品負責人是必要的人，其餘對『精煉會議』要討論的主題有幫助的相關人員如『部分』（我傾向至多兩位）開發團隊（Development Team）、UI/UX（可能不在開發團隊）、資料分析師（Data Analyst）、利益關係人（stakeholder）等。

Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.
If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.
I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.