iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 10
0
Software Development

團隊導入Scrum會遇到的30個問題系列 第 10

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

[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再討論新的。


上一篇
[Day 8] 估計的精準度
下一篇
[Day 10] Commitment是歃血為盟的承諾
系列文
團隊導入Scrum會遇到的30個問題30

1 則留言

0
herdyboy
iT邦新手 5 級 ‧ 2020-10-06 14:51:34

PBR 想要好奇的問,好像scrum 裡面也沒有特別說那個時間點比較適合做這件事?
如果要做是在計畫會議之前還是之後做比較適合?

SamHuang iT邦新手 5 級 ‧ 2020-10-12 12:00:10 檢舉

我遇到的情況通常是在計畫會議之前做比較適合。
原因是對item瞭解之後會幫助PO和團隊的計畫。
你們可以試試囉。

我要留言

立即登入留言