スクラムでよくある話に、ストーリーがスプリントで終わりきらないというのがある。
スコープは約束ではないから、できなくてもいいとも言えるが、スプリントプランニングで自分たちで決めたスコープにも関わらず、残ってしまうのは進め方が悪いことを露呈しているようなものだ。
スプリントで選んだストーリー(バックログ)が終らない原因はいくつが考えられるが、理由の1つに、スプリントに「準備できていない」バックログを投入してしまうことがあげられる。
準備不十分なバックログは、準備してから実装することになる。だが短期スプリントだと、準備している間に終ってしまう。スプリントが開始したら直ちに実装作業に入れるように「準備できた」バックログを投入しなくてはならない。
「準備できた」とはどのような状態のことだろうか。
- ユーザーストーリーが具体的で明快である
- 受入基準がある
- デモの手順がわかる
- 開発チームによって見積られている
- 他のバックログと依存関係がない、またはあっても速やかに調整し、解消できる
- 外部に依存するパーツや部品が含まれてない
- 不透明なことがない(スプリント開始後に出てくるかもしれないが、スプリントを始める時点で曖昧なことがない)
- 調査不要で、すぐ着手できる
- 実装イメージが沸く
(スポンサーリンク)
英語で”Ready”を調べて見ると次のように説明がある。
Ready: prepared for immediate action/use すぐに行動に移したり、使い始めたりすることができる状態
リレーでも、”On your mark”, “Ready”, “Set”, “Go”である。
射撃でも、”Ready”, “Aim”, “Fire”である。
スプリントが始まったらすぐに飛び出せるようにストーリーを準備しておこう。
「完成の定義」と並んで、「Readyの定義」も作ろう。
バックログが「準備できた」かどうかは、Bill Wake氏の”INVEST”要件を満たしているかどうかで判断できる。最初はチェックリスト的に使ってもいいだろう。
(Source: Manifesto)
Readyの定義 → スプリント(実装) → 完成の定義 がワンセットだ。
スプリントプランニング時に、スプリント期間で完成の定義を満たせるか判断しよう。準備ができていないなら、スプリントで実装できると判断がつくまで具体化してからはじめよう。
ジェフパットン氏の名著「ユーザーストーリーマッピング」。スクラムチームと利害関係者が集まって話し合うことで、顧客ニーズとリリース順位が明確になる。お薦めです。
![]() |
新品価格 |