30日ではなく30日以内ではなく、むしろ「30日を待たずに30日で検証できる粒度に切る」 という設計が現実的です。スクラムではスプリントは1か月以内が推奨され、一般には2週間程度が多いため、90日単位の検証ではなく、1〜4週間の短い反復で価値を確認する前提に寄せるのが整合的です。
設計の考え方は、「期間」ではなく「検証可能な成果物」から逆算することです。スプリント内でレビュー可能なインクリメントを作り、スプリントレビューでステークホルダーに提示し、次の学びにつなげます。
-
スプリントゴールを検証仮説で書く
例: 「この機能で新規登録率が改善するかを確認する」 -
30日で1回の大きな検証ではなく、1〜2週間ごとに小さく検証する
スプリントは短期間で成果物を作る前提で、通常は1〜4週間です -
“完成”をスプリント開始時に明確化する
Definition of Done を確認し、コードだけでなくテストやレビューまで含めて完了条件を揃えます -
ストーリーは横断的に切る
UI、API、DBを分断せず、1つのストーリーで「ひととおり動く」状態を目指すと検証しやすくなります -
事前準備を入れる
スプリント開始後に要件確認やゼロからの設計を始めると、対処が難しくなるため、上位のPBIはReadyにしておきます -
レビューで学びを確定する
スプリントレビューは、完成したインクリメントを見せて進捗と方向性を確認する場です
90日で検証したい内容があるなら、90日を1つの検証期間として抱えるのではなく、30日×3回または2週間×6回のように分割し、各スプリントで仮説・実装・レビュー・修正を回す設計にすると、学習速度が上がります。
必要なら次に、「30日で回すスプリント設計テンプレート」 を、
目的・仮説・バックログ分割・レビュー観点・KPI まで含めてそのまま使える形で作れます。
