Refinement Meeting 要不要開？

作者：
我的答案是「要」。但可以依照 Context 不同而不同。







Scrum guide

 

先來看看 scrum guide。

你假如用 refinement 當關鍵字去 scrum guide 裡面 search，你只會找到四個，全部都在 product backlog 章節。

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.

假設你跟你的團隊沒有開 refinement meeting，你是不是有做到 adding detail, estimates and order？有去 review, revise product backlog items 嗎？你跟你的團隊只要做到這些事情，沒開會又如何？因為 refinement 應該是一個 on-going process，讓 PO 可以任何時間都去更新 product backlog。

假如有開 refinement meeting，那你應該會比較容易做到以上那些事情，因為會讓這些事情刻意的在會議上發生。

所以我覺得應該要開這個會。

讓我再舉一些我自己帶過的團隊的實際的例子，但因為太實際了，所以只能說個大概。 XDDD






四個人的 scrum team:

 

最近我也當起了 PO，我有一個很強很強的架構師：安德魯，還有兩個成員，加我，一共四個。

我們是一隻特攻隊，目標就是很快的做出架構上的調整與雛形，然後移交給自己公司的 backend 工程師使用，所以，在與 refinement meeting 相關的方面，我的實作方法：

  1. 我們的 Product Backlog 不是一個 list，是 impact mapping，我會常常去修改他
  2. 不做 PBI level 的估計
  3. 不特別開 refinement meeting，都用日常的討論或是直接跟 planning meeting 一起討論掉了。

因為，我的團隊只有 3 個人，且我的 sprint 是一個禮拜，所以如果你要抄的話，請三思而後行。






超過九個人的 scrum team:

 

以下我來講一下，我在比較多人的時候的 refinement meeting 的開法：



兩個 Development team 的團隊

 






這張相片是 2018 的夏天，我當時的團隊做 refinement meeting 的樣子。後面坐那一排是兩位設計師與兩位主管，前面圍成兩圈的是兩個標準 size 的scrum team，加起來大約 17 人吧。

在這個團隊，我的實作方法是：

  1. Product Backlog 放在 VSTS 上，是一個 list 的形式。
  2. Sprint 長度兩個禮拜。
  3. Refinement meeting 兩個小時，偶爾會超過一點點。
  4. 在 Refinement meeting 上，做 PBI-level 的估計。
  5. Sprint 目標老實說，沒做得很好，並沒有非常非常明確，但我們盡力降低 Epic level 的 WIP。

 

 

 

四個 Development team 的團隊

 

是現在(2019 春)的團隊，沒有拍照… 以後再補吧…，分為四個團隊，團隊人數剛好是 5566，五個五個、六個六個。加起來 22 個。

在這個團隊，我的實作方法是：

  1. Product Backlog 放在 VSTS 上，是一個 list 的形式。
  2. Sprint 長度兩個禮拜。
  3. Refinement meeting 一個小時～一個半小時，看 Epic 大小，由一到三個 dev team 一起 refine，或個別團隊 refine，或 PO 找 keyman refine。
  4. Refinement meeting 不強制該團隊所有人都要參加。
  5. 不做 PBI-level 的估計。
  6. Sprint 目標盡量明確，但試著提升 Epic-level 的 WIP。

(不要問為什麼，我說不完，我只能說是為了要 Align business)







五個 Development team 的團隊

 

2017 年初吧，好久以前了，那時候傻傻的，依靠一股打不死的熱情與兄弟姊妹們的相挺，莫名其妙就跑起來了。再次感謝當時各位朋友們、長官們的信賴、照顧與幫忙。






這張圖有五個團隊，一個團隊 10 個人，每一個團隊都是 fully-feature team，每一個 dev team 裡面都有前台、後台、前端、QA、前 PM、Android、iOS，甚至，五個團隊裡面有兩個團隊有設計師，不在開發團隊內的只剩下三個人：PO、我跟另外一個 scrum master。

當時覺得就這樣啊，後來才知道這樣的配置超夢幻的。

總之，跟 refinement 的相關的實作方法，我那時候是這樣：

  1. Product Backlog 在 Redmine 上，是 list 的形式。
  2. Sprint 長度兩個禮拜。
  3. 在 Refinement meeting 之前，會有會前會，七個前 PM 會帶著自己的 User Story 來，輪流提案給 PO，並最後由 PO 排序。
  4. Refinement meeting 兩個小時，偶爾會超過一點點。
  5. 在 Refinement meeting 上，做 PBI-level 的估計。

之前有在社群做了分享，投影片連結在此。





最近聽到的關於 refinement meeting 的問題

 

有人把 refinement meeting 放在 retrospective 後，然後下一個工作天就開 planning meeting 了，問我的想法。我是覺得蠻少見的，如果是我，應該不會這樣安排啦…

有人問說，refinement meeting 要不要先把 acceptance criteria 寫好？我的團隊是沒在寫啦… (羞愧)，但我覺得應該要寫，只是我們壞壞，沒寫。

有人問說，refinement meeting 要不要全員參加，我覺得要，因為一個 Sprint 往正確的方向只前進一小步，都比往錯誤的方向前進三大步要好、更少浪費，而全員參加可以讓大家一起往正確的方向前進的機會要大一點。但我現在的團隊沒有全員參加。Mike Cohn 這篇文章說，估計的時候要全員參加，可能有點類似我的想法吧？


Reasons to Estimate During Planning Poker with the Whole Team
A well-established best practice is that those who will do the work, should estimate the work, rather than having an…www.mountaingoatsoftware.com

 

 

 

 

這一直都沒有標準答案的

 

我們就都不是學生了，哪裡還有標準答案？ refinement meeting 要不要開、要怎麼開，哪還有可能有標準答案？

所以 scrum master 在面臨關於 refinement meeting 的決策時，你的團隊、你的公司、你的 PO 甚至是你的會議室，都會影響你的決策。決策 A 會有好處 A 也會有壞處 A；決策 B 會有好處 B 跟壞處 B。當這個 refinement meeting 的決策下下去，比如說，用了 A，那就應該會享受到好處 A，同時也要承擔壞處 A；基本上沒有一個決策可以讓你同時拿到好處 A 跟好處 B 的。

而大概，大部分的團隊會聽 scrum master 的。

所以，沒有標準答案，三思而後行，想一下真正的問題是什麼？你要解的問題是什麼？





 

做了以後，假如狀況不對，馬上修改，該認錯就認錯 XDDDDD，這樣才敏捷。所以我現在都… 「啊～幹～你們要怎麼開就怎麼開啦～」

你呢？你是怎麼做 refinement 的？留個言吧？









留言

張貼留言