ブログ

みなさんこんにちは。@ryuzeeです。

スプリントプランニングでは、スプリントの終了までに「どのプロダクトバックログアイテムを完了させるか」を計画します。

このコミットメントとは何なのか？先日のCertified Scrum Product Owner研修でジェフ・サザーランドさんに以下のどれなのかを聞いてみました。

プロジェクトの初期段階の数スプリントでは、見積りの精度は低いし、自分たちのベロシティがはっきりしていないので、通常はオーバーコミットしがちです。 またそもそもスクラムの経験が豊富ではないチームでは、「プロダクトバックログアイテムを完了にする」ことに対する理解がすくなく、スプリントを始めてから、自分たちの見積りが甘かったことに気づいたり、スプリント0で行っておくことが望ましい技術的なスパイクを行っていなかったために、なかなかバーンダウンが落ちていかなかったり、といった状況に直面しやすいものです。 プロダクトバックログアイテムの分割が不十分だったり受け入れ基準（Acceptance Criteria）がはっきりしていなくて、そもそもReadyではなかった、ということも考えられます。

この状況下において、もしコミットが1を意味していたらどうなるでしょうか？

• チームは表面的な完了を得るためにテストやリファクタリング等の見えにくい箇所を省いたりするかもしれない
• 頑張ってメンバーみんなで大量に残業するかもしれない

特に「コミット」について、強い力を持つ顧客や経営が意味をはき違えていると、ここでチームは透明性をなくし、自己組織性を失い、製品に対する情熱を失うようになります。 コミットした内容を無理やりでもやり遂げようとした場合、後続のスプリントに技術的負債を残してしまう可能性もあります。 また、そもそもソフトウェアは不確実性の高いものであり、決めた計画がすべて正しいわけでもなく、見積りがすべて正しいわけでもありません。 そのような不確実なものをチームｘスプリント期間という固定リソースの中で「完成」の保証ができるはずがないのです。

なお、最初の数スプリントはオーバーコミットしやすいのは前述の通りですが、オーバーコミットが数スプリント続くような場合は、チーム自体に問題があるとも言えます。 チームはスプリントの終了後に次のスプリントに向けてレトロスペクティブ（ふりかえり）を行い、改善していく必要がありますが、オーバーコミットの改善も当然対象に含まれます。 そのスプリントでオーバーコミットになってしまった理由は何なのか？ チームのベロシティはいくつなのか？ タスクの見積時間の合計がキャパシティ内に収まっているのか？ などなど確認すべき点はたくさんあります。 これらができていないならチームは自己組織化されていないし、検査と適応のループが回っていないのです。 また、毎回アンダーコミットしてしまうようなケースは、コミット内容を守ることに対して強い圧力がかかっていることが想像できます。 圧力がかかったチームは創造性も生産性も確保しにくいものなのです。

ということでジェフの答えは2でした。