実際の事例でスクラムの枠組みを学ぶ！意外な発見があるかもしれません！

最初のスプリントの前

アレックスは、新しいソフトウェア開発プロジェクトのプロダクトオーナーです。最初の仕事の一つは、要求を評価し、明らかにすることです。顧客が求める事業価値を届けるためです。

顧客に、具体的な事業成果を実現する、正しいソフトウェアが届くようにする必要があります。重要なユースケースを書き出し、アーキテクト、顧客代表、IT部門と事業部門の関係者と話し合います。（関連項目： スクラムの実例)

大まかなユースケースと要求を集めた後、それらをスクラムプロダクトバックログに記入し、スクラムチームと見積もりと優先順位付けを行います。その結果、すべてのアイテムに、最初の大まかな見積もりと優先順位が付きます。

この場で、スクラムマスターのアンナは、全員が同じ意味で言葉を使えるようにします。プロダクトオーナー、チームメンバー、ステークホルダーが、期待するゴールについて認識を合わせます。そして、初めてかもしれない概念を、十分に理解します。ユースケース、バックログ、スプリントなどです。そして何より、職場でスクラムの開発とデリバリーのプロセスを正しく適用できるようにします。

次にアレックスは、大まかな要求を、小さなユーザーストーリーの初稿に分け始めます。その一覧を用意し、最初のスプリントプランニングを開きます。

スプリント1 — 0日目

そのスプリントプランニングミーティングで、アレックスは、プロダクトバックログアイテムを優先度の高い順に提示します。チームは未解決の質問を挙げ、明確にします。各アイテムについて、開発し、届けるためのキャパシティとノウハウがあるかを話し合います。そして、スプリントの開始前に、必要な人的・技術的リソースがすべてそろうよう確認します。ソフトウェアの機能を届けるうえで重要な、前提条件と依存関係が満たされていることを確かめます。

このスプリントプランニングのWHATパートで、開発者は、合意したスプリントゴールを支えるため、ユーザーストーリー1,2,3,6,7と8を、スプリントの終わりまでに完了できると予測します。そこで、これらをプロダクトバックログから、スプリントバックログに移します。ストーリー4と5は、前提となる技術基盤の一部がまだないため、このスプリントでは完了できません。

WHATパートの後、スクラムマスターのアンナは、チームに、取り組むとしたストーリーをどう実装するか、詳しく検討するよう求めます（HOWパート）。そこで明らかになったタスクをカードに書き、スプリントバックログに入れます。これで全員が、タスクを選んで取り組み始める準備ができました。

スプリント1 — 1日目

朝、開発者が集まり、デイリースクラムを行います。各自が、短く簡潔に説明します。これまでに行ったことを伝え、スプリントバックログのカードの残り作業の見積もりを更新します。今日の予定を話し、タスクの作業を妨げる障害があれば明らかにします。

今日は、メンバーのメリンダが、使っている統合開発環境のライセンスに問題があると伝えました。アンナは、ほかの人にも同じ問題があるかを確認し、ミーティング後に対応すると約束します。およそ 15分でデイリースクラムを終え、全員が仕事に戻ります。

その後、アンナは、スプリントバーンダウンチャートを更新し、このスプリントの進捗を見えるようにします。それからベンダーに電話し、不足していたライセンスを注文し、メリンダに渡します。

原寸大の図を開く

リンク先の資料へ進む

スクラムの各段階とスプリントを通じた、実際の事例による入門

スプリント1 — 2日目

朝、開発者は再び集まり、デイリースクラムを行います。午後、メンバーのジェームズが、あるユーザーストーリーの期待する成果について、よく分からない点を見つけます。プロダクトオーナーのアレックスに連絡して話し合い、正しく理解しているかを確かめます。進め方に自信が持てたら、実装を続けます。

スプリント1 ― 6日目

再びデイリースクラムで一日が始まります。今朝、アンナは、データベースクエリの最適化についてメンバーが議論し、15分を超えそうだと気付きます。そして、デイリースクラムは長い技術的な議論の場ではなく、スプリントゴールへの進捗を検査し、開発者の計画を適応させる場だと伝えます.

。その後、アレックスは、顧客から、進行中と今後のスプリントに影響しそうな新しい要求がいくつか出たと伝えます。アンナは丁寧に、変更によってスプリントゴールを危険にさらしてはいけないと伝えます。選んだストーリーをすべて変更不能な約束とするのではなく、学びに応じて、開発者とプロダクトオーナーが範囲を明確にし、再交渉できます。そこでアンナは、午後に、バックログリファインメントのミーティングを設け、アレックスが新しい要求をチームに伝えられるようにします。

この場で、皆はアレックスを助け、新しいストーリーが全体の開発計画のどこに入り、最初にどうタスクへ分け、見積もり、優先順位を付けるかを考えます.

スプリント1 ― 10日目

いよいよ最初のスプリントの最終日です。アンナがチームを、スプリントレビューミーティングに招きます。チームは、作成した出荷可能なインクリメントの最新版を、本番以外のサーバーに用意しました。

アレックスと、顧客側の関係者のリッチ氏が、ソフトウェアのグラフィカルユーザーインターフェースの前に座ります。そして、実装が期待に合っているかを確認します。また、アプリケーションの現在の状態が、十分に詳しく文書化されているかも確かめます。

スプリントレビューの終わりに、アレックスは次のようにまとめます。

チームは、ストーリー1,2,6と7を、約束と期待どおりに届けた。
ストーリー3は時間内に完成せず、実演もしなかった。未完了のストーリーはプロダクトバックログへ戻し、順序を見直す。残りの作業は、次のプランニングで選択できる。
ストーリー8は、共通の完成の定義（DoD）を満たさなかった。プロダクトバックログへ戻し、受け入れ基準と残りのタスクを明確にしてから、再び選ぶ時期を決める。

アレックスと、顧客側のリッチ氏は、チームに手短に伝えます。今後の要求の変更と課題、そして、このソフトウェアの全体的な戦略の方向性についてです。リッチ氏は、チームの努力と取り組みに感謝し、退室します。

レビューを終えた後、チームが集まり、スプリントレトロスペクティブを行います。スプリントでうまくいった点と改善点を話し合い、今後の予測を高め、ストーリー3と8の問題を繰り返さないようにします。見つかった障害の一つは、チームのシステムアーキテクチャ全体についての知識が不足していることです。アンナは、次のスプリントの初めに、システムアーキテクトを招いてチームに指導と助言をしてもらう仕事を引き受けます。