今回は、スクラムイベントのスプリントプランニングに関しての話です。
スクラムガイドのp.9 ですね。
プランニングの材料について
スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チ ームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数に ついては、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チーム だけである。
インプットとして最新のプロダクトインクリメントとあります。どういう意味でしょうか？
これは、たとえば、スプリントレビューで発見した新しい業務パターンへの対応をストーリーに含めるとか、要件定義中の新機能に追加要望を入れることなどが該当するようです。
スプリントゴールへの言及
スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するも のである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールは スプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終 了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機 能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チ ームは一致団結して作業ができる。
スプリントゴールって解釈が広い概念だと思います。インクリメントとして届けられる時もあると思いますし、「新機能の実装にどれくらい現状のコードを改修しなければならないか」といったボリューム調査になる時もあるでしょう。
スプリントゴールを設定することで、ストーリーのフィーチャが現状の実装と合ってなかったら調整することも出来るのかなと思いました。
たとえば、業務フローを3パターン新しく追加したい場合、うまくいかない可能性を考慮して、最小限の実装でスプリントレビューできる業務フローを作成するとしても良いですね。最低1パターンできればOKですね。実装がめちゃくちゃ大変そうだと分かったときは、TDD前のスパイクへ方針転換することもできますね。
スプリントゴールは、抽象的な表現になってもいいと思います。柔軟にするということは、解釈の幅を広げるということですし。1%でも改善が出来ればそれで良いと思います。
スクラムに馴れてないチームがプランニングをするときの注意点
できるだけ小さいゴールを設定して、達成感を得られるようにすることが大切だという話が出てました。ただ、最小限のゴールさえ達成できなかったら無力感がすごいらしいです。。自分も経験ありますが、初めてスクラム開発を行う場合、ベロシティの計測も出来ていない状態なので、ストレッチゴールを設定しがちです。ベロシティが安定するまでは、自分たちができると思っていることよりも、１つ少ないことをやるようにすると良いと思いました。
