釐清故事內容
當團隊會自豪地，在Sprint展示會議中展示一個新的功能，最糟糕的事是產品負責人皺著眉頭，並說：“是的，看起來不錯，但是那不是我要的。”
你如何確認產品負責人和團隊有相同的認知呢？或是團隊中每個人對故事有相同的理解呢？嗯，你可能無法確定。但是有一些簡單的方式，可以幫忙找出最明顯的誤解。最簡單的方式就是確保故事中，所有的欄位都被填寫(或是更具體地說，對於那些有高優先順序，需要在這個Sprint中完成的故事，都需要填寫)。
有些人稱之為”準備好的定義” 。所以，做完的定義，是當故事完成時的檢查清單，而準備好的定義，是當故事準備好可以被拉到 sprint 時的檢查清單。非常有用。
範例1：
團隊和產品負責人對於Sprint的計畫很滿意，打算結束會議。這時候Scrum master問說：“等一下，這裡有個“增加使用者”的故事還沒有估算時間，讓我們來評估吧！經過幾次計畫紙牌投票，團隊同意它的故事點數是20。這時候產品負責人站起來，大聲說道：“什…什…什麼？”在經過幾分鐘的爭吵，最後發現是團隊誤解了故事的範圍，他們認為這只是要“提供一個漂亮的使用者介面，來增加，移除，刪除，和搜尋使用者”，但是產品負責人認為它只是“手動透過SQL指令去增加使用者到資料庫中”，所以他們再評估一次，給了這個故事5個故事點數。
範例2：
團隊和產品負責人對於Sprint的計畫很滿意，打算結束會議。這時候Scrum master問說：“等一下，這裡有個“增加使用者”的故事還沒有說它要如何展示？”在一陣七嘴八舌之後，某個人站起來說：“嗯，首先我們登入網站，然後…”，這時候產品負責人打斷說：“登入網站？”不，不，不，這個功能並不包含在這網站裡面，應該只要給有技術背景的管理者，一些簡單的SQL，它就能夠執行了。
故事中"如何展示"的描述，需要(最好應該)非常精簡！ 否則你就沒辦法準時結束Sprint規劃會議。基本上，它應該是非常平鋪簡單的敘述，來描述如何手動執行最具代表的測試流程。"先做這個，然後那個，最後再確認這個"
我發現，這種簡單的敘述，往往可以發現到，團隊對故事嚴重的誤解。這種事早點發現會比較好，不是嗎？
我仍然喜歡這個技巧。每當有故事很模糊時，就會使用它，可以讓事情具體化。另一種做法，是畫出低真度的草圖，或是準備驗收標準的列表。把故事想像成一個高層次的問題敘述，而做完的定義，則是當它完成後，看起來會長怎樣的具體範例。
全站熱搜
留言列表
