ケーススタディー
シナリオ
このスクラムチームは、自社製品の新しいメジャーリリースに取り組んでいます。
3スプリント前、プロダクトオーナーはロードマップを作成し、20の機能を開発するには10スプリントが必要になると予測しました。
今朝、3回目のスプリントが終了しましたが、この3回のスプリントで開発されたのは3つの機能です。さらに、開発者たちは、これらの機能はまだ十分にテストする必要があると言っています。
一方、プロダクトオーナーは、ユーザーはすでに出来上がっている３つの新機能にアクセスできることを喜ぶだろうと考え、それらの機能を今からリリースしたいと考えています。
チーム内には現在、緊張感が漂っています。
質問
- このような状況について、どう思いますか?スクラムが機能しているように見えますか？
- もしあなたがプロダクトオーナーなら、どうしますか?
- もしあなたが開発者なら、どうしますか?
- もしあなたがスクラムマスターなら、どうしますか?
- 誰がどのような決定に対して説明責任を負うのでしょうか?
一つの答えとして
注意点：短いケーススタディーを読んだ際に、あなたと私が認識する内容は異なる可能性があります。さらに、複雑な環境では、1つの特定の状況に対処する方法が複数あることがよくあります。つまり、これは単に「一つの答え」でしかありません。
このような状況について、どう思いますか?スクラムが機能しているように見えますか？
チーム全体に透明性が欠けており、特に「完成の定義」に対する理解や共通認識が不足しているように思われます。また、プロダクトオーナーと開発者の間で優先順位やリリースの条件に対するギャップがあるため、現在の緊張感が生じていると考えられます。この状況では、リスクを無視して未完成、未テストの機能をリリースすることは、ユーザーの信頼を損なう恐れがあり、慎重に対応する必要があります。また、プロダクトオーナーが当初ロードマップを作成し、10のスプリントで20の機能を予測するためにどのようなデータを使用したのかも不明です。もしかしたら、プロダクトオーナーの当初の予測（期待？）が開発者にとって不健全なプレッシャーを生み出したのかもしれません。
もしあなたがプロダクトオーナーなら、どうしますか?
プロダクトオーナーとして、ユーザーに機能を迅速に提供したい気持ちは理解できますが、まずは開発者のフィードバックに耳を傾け、テストが十分に行われていない機能をリリースするリスクを認識する必要があります。以前予測していたよりもチームの進捗が遅れているため、ロードマップを更新するのをお勧めします。過去のデータ（存在する場合）を使用し、スクラムチーム全体を関与させることを確認しながら、予測の方法を再考する必要もあるようです。また、もし、最初の3つの機能をユーザーにリリースすることが、プロダクトオーナーが考える最も価値のあることであるならば、リスクや技術的負債を増大させることなく、スプリントプランニングを利用して、できるだけ早くそれを実現するための計画を立てます。その中で、開発者になぜ早くリリースする必要があるのか（機会を失う恐れがあるからなど）を説明します。
もしあなたが開発者なら、どうしますか?
前進するにつれて透明性を維持し、実際の進捗状況が誰の目にもできるだけ早く明らかになり、より良い意思決定ができるようします。
プロダクトオーナーと残りのテストの目的と必要性を話し合い、スクラムチーム全員で「完成の定義」を定義し、それにコミットします。少なくともスプリントごとに1回は、「完成の定義」を満たすインクリメントが作成され、検査されるようにします。それが現時点では不可能なら、その根本原因（チームの権限の問題？スキルの問題？その他？）を特定し、解決できるように働きかけます。
複雑な作業には本質的に不確実性が伴うことを認識しつつ、信頼性のある予測を行うためにプロダクトオーナーと協力します。
もしあなたがスクラムマスターなら、どうしますか?
チームの最終目標と目的を思い出させます。
信頼を損なうような行動（ユーザーからの信頼も、スクラムチーム内の信頼も）からチームを守ります。
次のスプリントイベント（スプリントレトロスペクティブ、スプリントプランニングをはじめ）を活用し、チームが現在直面している問題の解決を導きます。
全員が当事者意識を持ち、起こったことから学べるよう、全員を現在の状況に対処するプロセスに関与させます。
また、プロフェッショナル意識を維持し、スクラムの価値基準（勇気、公開、集中、尊重、確約）を体現するような行動や話し方を心がけます。
必要に応じて、チームが今後同様の状況に陥らないよう、役立ちそうなテクニック（アジャイル開発を支援するテスト手法、見積もりの仕方、ロードマッピング、など）をチームに指導します。
誰がどのような決定に対して説明責任を負うのでしょうか?
開発者は、使用可能な状態で、高品質のインクリメントを作成し、（そのための計画を含む）スプリントバックログを管理する責任があります。
プロダクトオーナーは、プロダクトバックログアイテム（新機能等）の優先順位付けに責任を負い、「完成の定義」を満たしたインクリメントのリリースを要求する権限を持ちます。
スクラムマスターは、スクラムチームの有効性に責任を負います。そのため、もし上記のことが行われていない場合、または効果的でない場合、スクラムマスターはチームがそれらの問題に対処し、時間とともに改善していくことを確実にする責任があります。スクラムマスターはティーチング、コーチング、メンタリング、問題解決、ファシリテーションなど、様々な姿勢を組み合わせることで、それを実現します。
このケーススタディーが参考になりましたら、ぜひ共有をご検討ください！
スクラムについてもっと知りたいですか？
弊社が提供している認定プロフェッショナルスクラム™研修は以下の４種類になります。パブリック形式もプライベート形式（一社向け）も両方提供しております。詳細についてはそれぞれのページをご確認ください。
