スクラム道バーストに参加した感想＆doneの定義の話

2011/06/24にスクラム道バーストに参加してきました。申し込みを忘れていたのですが、当日行けそうに無かった方のご好意で代わりに参加してきました。@ledsunさんありがとう。

内容は過去のスクラム道の再演とトピックに対する議論の場でした。詳しい内容は他の方の素晴らしいレポートがあるのでそちらをご参照くださいw

選手ってなに？ってことが良くわからないまま選手として参加してしまいましたが、壇上に上ってもそんなに緊張しないものですね。変なこと言っても殴られたりしないので、このような形式があったらどんどん選手として名乗りをあげるといいと思います。

---

スクラム道バーストで「doneの定義を拡大/縮小することの是非」がトピックに上がりました。思い返すとストーリーのdoneの定義なのかタスクのdoneの定義なのかがあやふやだったので、それぞれ検討しました。

結論としては、拡大するにしろ縮小するにしろ、スプリントバックログをいじるのでプロダクトオーナーの判断が必要。拡大は（こなせるのであれば）問題になることはあまりないが、縮小はリリース時期や提供価値に影響が大きいので要注意。となりました。

ストーリーの場合

ストーリーのdoneの定義を変更するのはプロダクトオーナーの承認が必要。ストーリーをスプリントバッグログにいれる判断はストーリーが提供する内容に対する判断なので、doneの定義が変わった場合はストーリーが提供する内容が変わるはずだから。

doneの定義を拡大したい場合

スプリント内で追加するタスクが達成可能かの見積もりをした上でシステムに価値が向上するかをプロダクトオーナーに確認する（ストーリーのdoneの定義が拡大するということはタスクが追加されるはず）。プロダクトオーナーはもしかすると他のストーリーをスプリントに追加したいかもしれない。

doneの定義を縮小したい場合

縮小するということはストーリーのタスクをいくつか落とすことを意味する（ストーリーのdoneの定義に影響しないならタスクはチームの判断で落としてよいが、その場合は「ストーリー」のdoneの定義の縮小にはあたらない）。タスクを落とした結果、ストーリーの提供する価値がどのように変化するのかをプロダクトオーナーに提示して判断を仰ぐ。

• 他のストーリーのスプリントバックログから落とすことで当該ストーリーをdoneさせる
• 当該ストーリーを落として他のストーリーに入れ替える
• ストーリーを分割して、達成できないストーリーをプロダクトバックログにいれる
• あるタスクがブロック要素となっている場合はスクラムマスターにブロック要素の除去を要請する

などの判断などがありそう。

タスクの場合

タスクのdoneの定義の縮小がストーリーのdoneに影響を与える場合の対処は、ストーリーのdoneの定義の縮小と同じ。ストーリーのdoneに影響を与えない場合は縮小して問題ない。この場合はタスクを分割して不要なタスクを落とすことと同義。いまは必要ないという場合は他のストーリーのタスクとする場合もある。

doneの定義を拡大したい場合

タスクの所属するストーリーがスプリント内でこなせるなら、特に問題なし。しかし、そもそものタスクのdoneの定義がdoneしたとするには弱かったのではないか？という気もする。追加でこれもやっておきたい、はタスクの追加になるのではないか。

doneの定義を縮小したい場合

縮小したとして、それはそのタスクがdoneしたと言えるのかが問題。もし言えるのであればタスクが余分なものを含んでいたということ。言えないのであれば、それは縮小したからといってdoneしたということに意味が無い。ストーリーのdoneの定義に影響を与えるので、対処はストーリーのdoneの定義の縮小と同じ。タスクをdoneできない原因の対処はもちろん必要。