Sprint卡關

March 09 21:57~22:33

今天有位鄉民在facebook上問了Teddy一個與Scrum相關的問題，大意如下：

問：如果在跑scrum的時候原本所規劃的story遇到問題卡住了進行不下去要如何處理?

1. 直接修改sprint目標，變成變形的 task (這時候點數怎麼算?)
2. 再找大家重新開一次sprint planning meeting?
3. 誰有決定權，決定原本的task fail? (product owner?)

以下是鄉民的補充說明（原文照抄）：

目前是我們自己QA在run scrum
裡面有用一個task是 performance testing
原本要用RD寫的simulator，可是一直到sprint meeting以後
真的下去跑scrum才發現有問題，會跑不出我們預期要的結果
RD也不可能馬上改給我們
這個task很大，已經吃掉一整個sprint的時間(我們是以一周當成一個sprint)
如果要等RD，這個sprint就浪費了

***

依據鄉民的留言，Teddy揣測鄉民到以下情況：

1. 一個sprint只有一個story, 而該story有被細分為若干個task
2. 在sprint planning meeting之後才發現這個story根本不可能在這個一週的sprint中完成

關於這個問題Teddy記得以前好像有談過耶，不過文章太多一時也找不到是在那一篇談過這個問題，就再回答一次好了。

基本上，在sprint planning meeting之後才發現這個sprint所規劃的內容無法完成，或是臨時要改成去處理其他的事情，依據Scrum的精神應該要宣布這個sprint失敗，重新開始另一個sprint。不過，大家都不喜歡承認失敗…所以，如果sprint開始之後沒多久就要修改sprint goal與sprint backlog（理論上是不能改），那就改吧。不過千萬千萬要記得，這一招就跟三國演義裡面「諸葛亮火燒藤甲兵」一樣，有損陽壽，實為不得已而用之，不要三不五時傻傻地亂改。如果都到sprint demo前一天才發現沒有一個story可以完成，那就爽快宣布失敗，開一個retrospective meeting檢討一下失敗的原因再繼續計劃下一個sprint。

以上說明算是回答鄉民的前兩點問題，關於第三點「誰有決定權，決定原本的task fail」Teddy覺得鄉民沒有把問題講得很清楚，基本上Product Owner決定story是否有做完，但是Teddy不記得書上有沒有寫說task有沒有完成是否也是由Product Owner來決定。以Teddy的想法，task紀錄的是施工的內容，是否有做完應該是由開發人員來決定似乎比較合理。

另外，按照鄉民的留言推測，鄉民的一個sprint只有一個story，這種做法似乎風險太高了一點，因為這樣就沒有預留任何轉圜的餘地，要嘛就全部成功，否則就全部失敗。Teddy會建議是否可考慮把sprint長度增加為兩周，然後安排至少2-3個stories，或是把story切小一點，這樣子可以預留一些彈性。萬一原本預估的施工時間太長了，至少可以犧牲比較不重要的stories（至少完成一個最重要的）。

以上，報告完畢。

***

友藏內心獨白：拜託多問點問題Teddy才有料可以寫啊。