• これは、開発開始前に、プロダクトオーナーとそのストーリーを担当する開発者のペアが共同でウォークスルーや説明を行うプラクティスです。

• 開発者（とその他）はこの機会に疑問点を解消し、ストーリーをタスクアウトしたり、タスクを再確認したりします。

• 話の範囲が変わっていないか、変わっていたらどうするか、最後のチェックポイントです。

• タイムラグ

  スプリントプランニングミーティングでは、チームは次に取り上げられそうな様々なストーリーを議論することになリマス。この議論と実際にストーリーがピックアップされる時との間にタイムラグが生じ、コンテキストが失われることがあります。これは通常、持ち越されたストーリー、重要なバグ修正、休暇などのような、現実世界の影響によるものです。

• ディープダイブの欠如

  また、IPM（イテレーションプランニングミーティング）では、時間の制約や未決事項など様々な理由により、ストーリーの深堀りが行われないこともあります（これはチームやプロジェクトによって異なります）。

• コンテキストの変化

  たとえ深堀りが行われ、技術的なタスクが詳細化されたとしても、IPMと実際にストーリーが取り上げられるまでの間にコンテキスト・状況が変わっている可能性があるのです。

ストーリーのキックオフでは、ニーズを再確認すると同時に、ストーリーをより深く分析・検証する機会を提供します。

準備

• ストーリー

プロダクトオーナーは、分析を行った上でストーリーを準備する必要があります。つまり、ストーリーの目標、ユーザー、価値が明確になっている必要があります。また、受け入れ基準（アクセプタンスクライテリア）や前提条件も必要です。さらに、プロジェクトの状況に応じて、モックアップ、データ、スクリプトなどが必要な場合もあります。

• 参加者

理想的には、ストーリーに取り組む開発者のペアと、それをテストする品質担当者が最低限必要です。時には、ユーザーエクスペリエンスデザイナーやUI開発者、ストーリーの実現に関連する特定のスキルセットを持つ人たちを連れてくる必要があるかもしれません。もちろん、キックオフには、プロダクトオーナーやストーリーを書いた人も出席する必要があります。

時間

• 長さ

これが長編の最初のストーリーである場合、全員が同じページにいるように、チーム全員を招待する必要があるかもしれません。通常、機能の最初のストーリーは、説明のために多くの準備と時間を必要とする傾向があります。これが完了し、チームがその機能に慣れてくれば、かかる時間はかなり短縮されます。開発者が実際に作業を開始する前にキックオフを行いましょう。

• タイミング

よくある間違いは、キックオフを一日の終わり、昼食前、IPM前、あるいは開発者のどちらかが現在のストーリーに取り組み終わる前に行うことです。この場合、キックオフの目的、つまりストーリーに集中することが希薄になるため、キックオフの価値の一部が減少することを意味します。

実施

• 説明

開発者と品質担当に実際のストーリーを説明し、ストーリーの背景と受け入れ基準を明確に説明します。

• サポート資料

アプリケーションをあるウィンドウで開き、ストーリーそのものを別のウィンドウで、シーケンスなどの補足資料を別のウィンドウで開くとよいかもしれません。筆記用具を用意するか、ホワイトボードの横に置いてください。説明のための写真を撮り、ストーリーに添付することもできます。

• 質問

一般的に、最もシンプルなストーリーであっても、疑問が生じるものです。これらの質問のほとんどは、分析が明確であれば、簡単に答えることができるはずです。開発者/品質担当からのインプットに基づき、ストーリーに小さな修正が加えられるかも 知れません。会話の結果は、後で参照できるようにストーリーに記録されるべきです。

• 障害物

時には、より詳細な分析や他のステイクホルダーとの会話が必要な質問もあるかもしれません。このような場合、チームは、質問に関連するスコープを除外しながらストーリーを進めるか、質問に答えるまでストーリー自体をパーキングするかについて、判断を下すことができます。