有反應，有想法

August 13 08:59~11:00

▲Eiffel：多看多書應該可以累積一些想法

 

有一次去顧問一個Scrum團隊，第一次參加團隊的product backlog refinement workshop，他們進行的方式出乎Teddy意料之外的好。Product Owner和團隊藉由互相合作的方式，在這個活動中幫下個sprint預計執行的story訂定驗收條件。首先Product Owner解釋story，團隊成員對於不清楚的地方發問。了解story內容之後團隊成員接著估算story point，然後依據story的優先順序逐一在白板上寫出驗收條件。寫完驗收條件之後團隊成員向Product Owner解釋這些驗收條件，Product Owner再看看有沒有遺漏的地方。團隊成員透過撰寫驗收條件，向Product Owner回饋他們對於需求的理解，是一種不錯的互動方式。唯一的小缺點就是這種過程所花費的時間比較長，有時因為時間限制，無法幫當次所有的story都撰寫驗收條件，當下所撰寫驗收條件有時會遺漏一些特殊但重要的劇情。

觀察團隊幾個sprint之後，Teddy發現在sprint中間所舉辦的product backlog refinement workshop，似乎有點不夠「即時」。以Teddy以往的經驗，在sprint review之後，Product Owner很可能會因為sprint review所收集到的回饋意見而調整下個sprint的story。因此原本在product backlog refinement workshop所準備好的story便可能沒有被使用到。從精實開發的角度來看，這便形成了「半成品」。過多的「半成品」不但是一種浪費，也會拉長完成story的交期（lead time）。

Teddy和團隊溝通這個現象，但當時團隊成員並不覺得他們現行的作法有何不妥，因為product backlog refinement workshop可以讓他們提早排除下個sprint可能遭遇的外部阻礙，例如跟協力廠商協調互動的API。

Teddy所感受到的這個force（作用力）對團隊而言當時並沒有感覺，在向團隊分析完context、force、可能的solution選項，以及resulting context之後，這個「問題（或是說觀察結果、建議）」就先擺著，看看過一段時間是否會發酵，還是過了保存期限被丟棄。

過了幾個月之後，該客戶的另一個Scrum團隊的ScrumMaster跟Teddy提起product backlog refinement workshop的問題。在他們這個專案中，每次product backlog refinement workshop所遺留下來無法被排入下個sprint的story已經越來越多，所以他們準備試看看把product backlog refinement workshop和sprint planning part 1合併，看看能不能改善這個問題。

***

請問：

• 原本團隊決定在sprint進行中間舉辦product backlog refinement workshop有錯嗎？
• 另一位ScrumMaster是否表現得比較好，因為他促使團隊決定嘗試改變product backlog refinement workshop進行的方式？

Teddy覺得兩個團隊對於product backlog refinement workshop有不同的反應實屬正常現象，並不是「對或錯」的問題，而是他們所屬的context不一樣，面對的問題也不同，自然有不同解決方法。團隊一有比較多需要與協力廠商配合的story，所以在sprint進行中間舉辦product backlog refinement workshop協助他們處理些這外部相依性的問題。而且團隊一的product backlog相對來說比較穩定，因此他們在product backlog refinement workshop所規劃的story，大部分都會被排入到下個sprint，沒有被排入而累積在product backlog裡面的情況並不嚴重（至少團隊的感覺是如此）。

而團隊二的專案比較少外部相依性，所以原本在sprint中間舉辦product backlog refinement workshop的好處就減少很多，而這種「up-front design」雖然很輕微（不是big up-front design），但累積久了也是很可觀的時間花費。

***

Scrum不是一成不變的靜態活動，書上或是其他公司的做法可以參考，但照抄這些做法不加以思考，又可能變成〈貨物崇拜〉，飛機是不會因此而降落的。

***

友藏內心獨白：乾脆自己成立航空公司好了，愛在哪降落，就在哪降落。