[Day 9] PBR的出現，就足夠佔據我餘生的那些Sprint

問題:
團隊覺得Product Backlog Refinement討論太久了。

我們如何有效的進行Product backlog refinement?

問題分析:

• 會議中花最多時間的是哪一部分

SamHuang的看法:
我們可以先了解，團隊對"久"的定義是多長時間?
ScrumPrimer建議PBR不要超過一個Sprint 10%的時間。 如果是這樣，那5天的sprint, PBR不要超過半天可能比較恰當。有些團隊花比較多時間在估計點數的部分，討論比較多技術細節。

ScrumPrimer (https://scrumprimer.org/)

對策:

1. 不要處理，團隊一起多估計幾次情況自然會改善。
2. 介紹"相對"的概念，並和團隊一起找到用來比較的單位Item.
3. 注意團隊有沒有討論到過多的技術細節，建議把技術細節留在Sprint Planning part2 的時候再討論。
4. 把PBR放在禮拜五下午6點開始，大家想回家就會快速草草了事。

選擇對策:
2,3

執行:
即使團隊選用"比較"的概念做估計，也需要時間建立共同的知識，作為往後討論的基礎。
有些item, 團隊也需要討論到一定程度的技術部分，才能做相對的討論，也不需要完全禁止技術方面的討論。

討論清楚所花的講話成本，比沒討論清楚直接開始做然後做錯再改的成本低，所以做之前花時間討論是必要的。

我覺得refine 的時候要做的事情是在限制時間內讓大家對item價值的瞭解一致、確認驗收條件和估計。
在大家都知道時間有限的情況下討論必要的事，如果討論不完可以先停下。 討論太多之後也不一定能馬上全部實作完成，可以先做完refine完的item再討論新的。