【スクラム開発】完全ガイド｜流れ5ステップと役割

約 28 分で読めます

スクラム開発とは、1〜4週間の「スプリント」を繰り返し、毎日の共有と振り返りで計画を調整するアジャイル開発のフレームワークです。3つの役割と5ステップの流れ、運用でつまずかないコツまで一気に整理します。

1. スクラム開発とは？ ｜ 定義と3本柱を3分でつかむ

スクラム開発は、作るものを一度に全部決めてから作り始めるのではなく、短い期間に区切って「作る→見せる→直す」を繰り返す進め方です。区切られた1回の期間をスプリントと呼び、スクラムガイドでは1か月以内、実務では1〜2週間に設定するチームが多く見られます。

名称はラグビーのスクラムに由来します。全員が同じ方向を向いて一体となって前進する姿を、分業ではなくチーム一丸で開発する姿勢になぞらえたものです。

スクラムを支えるのは次の3本柱です。

• 透明性：今何が進んでいて、何が止まっているかが、チーム全員と関係者に同じ形で見えている状態
• 検査：成果物と進め方を定期的に点検する。スプリントレビューやデイリースクラムがその機会にあたる
• 適応：点検で見つかったズレを、次の計画にすぐ反映する

この3つは順番に並ぶものではなく、互いに支え合う土台です。特に最初の透明性が崩れると、検査も適応も形だけになります。「進捗が各自の頭の中にしかない」状態でスクラムを始めても回らないのは、この土台が抜けているからです。スプリントに入る前に、作業を誰が見ても同じ意味で読める単位まで落とす必要があります。どの粒度まで分解すべきかはタスクの粒度の考え方が参考になります。

2. アジャイル開発との違い ｜ カンバンとの使い分けまで整理

アジャイルは考え方、スクラムはその実装

多くの人が誤解しているのは、「アジャイル開発とスクラム開発はどちらを選ぶか」という対立の捉え方です。実際には対立していません。アジャイルは「変化に対応しながら価値を早く届ける」という価値観・原則の総称であり、スクラムはその原則を具体的な役割・イベント・成果物として定義したフレームワークです。つまりスクラムを実践していれば、それはアジャイル開発をしていることになります。

対比すべき相手はむしろウォーターフォール型です。要件を固めてから順に工程を進める従来型との違いを整理しておくと、社内説明もしやすくなります。工程を前もって並べる従来型の設計思想は工程管理の進め方に詳しくまとめています。

スクラムとカンバンの違い

同じアジャイル系でも、スクラムとカンバンは前提が異なります。

問い合わせ対応のように予定外の依頼が絶えず入る仕事は、スプリントで固定するとかえって破綻します。逆に、まとまった機能を期間内に形にしたいならスクラムが機能します。開発と運用を兼ねるチームは、開発案件をスクラム、割り込み依頼をカンバンで別レーンにするハイブリッドが現実解になりやすいです。

アジャイルはもう時代遅れ？

「アジャイルは時代遅れではないか」という疑問も定番です。時代遅れになっているのは手法そのものではなく、儀式だけをなぞる運用のほうです。毎日集まるが問題は解決されない、振り返りをするが何も変わらない——こうした形骸化が「アジャイル疲れ」の正体で、フレームワーク自体の否定とは分けて考える必要があります。生成AIの活用が広がり、仕様が短期間で変わる状況では、むしろ短いサイクルで方向を修正できる進め方の価値は上がっています。

3. スクラムチームの3つの役割 ｜ 誰が何を決めるのか

スクラムチームは3つの責任で構成されます。人数を増やすのではなく、決める人を明確にするための分け方だと捉えてください。

プロダクトオーナー（PO）

「何を、どの順番で作るか」に責任を持ちます。プロダクトバックログの内容と優先順位を最終決定する一人であり、複数人での合議制にすると優先順位が決まらず、スプリントが始まりません。

よくある誤解は、POをプロジェクトマネージャーと同一視することです。POが管理するのはスケジュールや工数ではなく、価値の順番です。営業・経営・カスタマーサポートから入る要望を、順位という一本の列に並べ直すのがPOの中心業務であり、そのためには社内外の利害関係者を整理する視点が欠かせません。利害関係者の洗い出しと優先順位の付け方はステークホルダーの整理方法で解説しています。

スクラムマスター

チームがスクラムを機能させられるよう支援する役割です。一般的なPMとの最大の違いは、タスクを割り振らない点にあります。スクラムマスターの仕事は、進行の妨げになっている要因を取り除くこと、会議が目的を果たしているかを見張ること、そしてPOと開発者の期待値がずれたときに対話の場を作ることです。

必要なのは技術力よりも、「その話は今この場で決める必要があるか」を判断してファシリテートする力です。デイリースクラムが報告会になっている、レビューで沈黙が続く、といった兆候に最初に気づくポジションでもあります。

開発者（開発チーム）

設計・実装・テストを担い、スプリントで何をどこまで作るかを自分たちで決めます。ここが自己管理型の核心で、上から配分されるのではなく、チームが自らの容量を見積もって引き受けます。だからこそ見積もりの精度が運用の質を左右します。見積もりの基本的な考え方は工数管理の基本が土台になります。

10人規模のSaaSスタートアップを想定して考えてみます。専任のスクラムマスターを置けず、開発リーダーが兼任するケースは珍しくありませんが、このとき起きやすいのが「兼任者がタスクも割り振ってしまう」問題です。兼任自体は現実的な選択でも、割り振りの権限までは持ち込まない、という線引きを最初に合意しておくと、自己管理型のチームが育ちます。逆にPOと開発者の兼任は避けたほうが無難です。作る人が優先順位も決めると、検査の視点が働かなくなるためです。

4. スクラム開発の流れ5ステップ ｜ 明日から回すための手順

ここからが実務の中心です。5つのステップは一度きりではなく、スプリントごとに繰り返す輪として回ります。

Step1　プロダクトバックログを作る

やりたいことをすべて一列に並べ、優先順位順に上から積んだリストがプロダクトバックログです。ポイントは「機能名」ではなく「誰が、何のために、何をしたいか」で書くこと。ユーザーストーリー形式（〜として、〜したい、なぜなら〜だから）にすると、実装前の目的確認が短くなります。

最初から全項目を詳細に書く必要はありません。直近2スプリント分だけ詳細化し、下位は粗いままにしておくのが現実的です。上位項目を詳細化するときの記述レベルは要件定義の基本の考え方がそのまま使えます。

Step2　スプリントプランニングで見積もる

スプリントの冒頭に行う計画会議です。POが上位の項目を説明し、開発者がそのスプリントで引き受ける範囲を決め、作業レベルに分解してスプリントバックログを作ります。

見積もりには、時間ではなく相対的な大きさを表すストーリーポイントを使うのが一般的です。フィボナッチ数列（1、2、3、5、8、13）を使い、「一番小さい既知の作業を2とすると、これはその何倍か」で決めます。時間で見積もると個人のスキル差が混ざりますが、相対比較なら全員の認識をそろえやすくなります。数スプリント回すと、チームが1スプリントで消化できる合計ポイント（ベロシティ）が見えてきて、そこから先の計画精度が一気に上がります。

作業への分解手順に不安がある場合は、WBSでの階層分解の手順を併用すると、抜け漏れが減ります。

Step3　スプリント実行とデイリースクラム

毎日同じ時間・同じ場所で15分。話す内容は「スプリントゴールに向けて進んでいるか」の一点です。よくある失敗は次の3つです。

• 報告会になる：上長に向けて昨日やったことを述べるだけ。ゴールへの距離が共有されない
• 問題解決を始めてしまう：15分で終わらず、関係ない人が拘束される。詳細は会後の別枠へ切り出す
• 全員が話すことを優先しすぎる：人数が多いと形式的な発言が並ぶ。ボードを画面に映し、動いていないカードだけを扱う

板の上で状況が見えていれば、口頭の共有は最小限で済みます。進捗の見せ方を整えたいときは進捗状況の共有の型が役立ちます。

Step4　スプリントレビュー

スプリントの成果を、関係者を招いて実際に動く形で見せる場です。スライドではなく動くものを見せるのが原則で、ここでのフィードバックが次のバックログに反映されます。POが「完成とみなすか」を判断し、未完了の項目はバックログに戻して優先順位を付け直します。持ち越しを既定路線にしないことが、見積もり精度を保つうえで重要です。

Step5　レトロスペクティブ（振り返り）

プロセスそのものを点検する会です。成果物ではなく進め方を扱う点が、レビューとの違いです。フレームワークは3つ覚えておけば十分です。

• KPT：Keep（続ける）／Problem（課題）／Try（次に試す）。日本のチームで最も定着している型
• Start-Stop-Continue：始めること／やめること／続けることの3列。「やめる」を明示的に扱えるのが強み
• Timeline振り返り：スプリント期間を時系列で並べ、感情の上下も書き込む。問題が起きた瞬間を特定しやすい

どの型でも、Tryを1〜2個に絞って次スプリントの作業として登録するところまでやらないと、振り返りは感想会で終わります。

ECサイト運営チームの2週間スプリント時間割

商品ページの改修とカート改善を並行して進める、ECサイト運営の10人チームを想定します。2週間スプリントを回す場合、各イベントは実際には次のような配置になります。

• 1週目・月曜10:00〜12:00：スプリントプランニング。「カート離脱率の改善」を今スプリントのゴールに置き、商品ページの表示速度改善とクーポン適用画面の修正を引き受ける。合計ポイントは前回までのベロシティ（例：34ポイント）を上限にする
• 1週目・火〜金 9:45〜10:00：デイリースクラム。在庫連携APIの応答待ちなど、動いていないカードだけを画面に映して扱う
• 1週目・水曜14:00〜15:00：バックログリファインメント。次スプリント候補（セール用LP、レビュー投稿機能）をユーザーストーリー形式まで詳細化
• 2週目・月〜木 9:45〜10:00：デイリースクラム
• 2週目・金曜14:00〜15:00：スプリントレビュー。マーケティング担当とカスタマーサポートを招き、改修後の購入フローを実機で通して見せる
• 2週目・金曜15:15〜16:45：レトロスペクティブ。KPTでTryを2つに絞り、その場で次スプリントの作業としてボードに登録

ECのように季節要因で割り込みが読める業種では、セール準備や問い合わせ増を見込んで、引き受けポイントを容量の7〜8割に抑えておくと持ち越しが減ります。期間の節目の置き方はマイルストーンの考え方も参考にしてください。

【保存版】スクラムミーティング・チェックリスト

イベントが形だけになっていないかは、終了時の数十秒で判定できます。以下は各イベントの締めにそのまま読み上げるためのチェックリストです。コピーしてチームのドキュメントに貼る、印刷して会議室に置く、ボードのイベント用アイテムのメモ欄に入れておく——どの形でも使えるようにしてあるので、司会者が交代しても抜けません。

• スプリントプランニング：スプリントゴールを一文で書けたか／引き受けた合計ポイントは前回までのベロシティの範囲内か／各項目の「完成の定義」を全員が同じ言葉で言えるか
• デイリースクラム：15分で終わったか／扱ったのは止まっているカードか／出てきた課題に担当者と期限が付いたか
• スプリントレビュー：スライドではなく動くものを見せたか／POが完了可否をその場で判断したか／未完了項目をバックログへ戻して順位を付け直したか
• レトロスペクティブ：Tryを1〜2個に絞ったか／そのTryを次スプリントの作業としてボードに登録したか

チェックが1つでも外れたイベントは、次のレトロスペクティブで扱う最有力候補です。このリストをボード上の「イベント確認」列として持たせておけば、毎回の判定結果がそのまま記録として残り、どのイベントが崩れやすいかも数スプリントで見えてきます。

5. メリットと「つらい」の正体 ｜ 続く形に運用を直す

4つのメリット

スクラムの利点は大きく4つです。仕様変更を次のスプリントで吸収できる柔軟性、手戻りの発生範囲がスプリント内に限定される効率性、短いサイクルで動くものを検査することによる品質の安定、そして関係者が実物を見ながら方向を確認できることによる満足度の向上。いずれも「短く区切って検査する」という同じ仕組みから生まれています。

「スクラムはきつい」と言われる3つの理由

ここが、多くの解説記事が触れずに終わる部分です。スクラムがつらくなるのには、はっきりした理由があります。

理由1：会議が多く感じる。プランニング、デイリー、レビュー、レトロスペクティブ、さらにリファインメント。イベントを足し算で導入すると、実装時間が削られたという体感が先に立ちます。

理由2：見積もりが約束に変わる。ストーリーポイントは本来チームの計画用の物差しですが、これを外部への納期コミットや個人の評価指標として扱い始めると、ポイントを盛る／削る駆け引きが発生し、数字が意味を失います。

理由3：役割の境界が曖昧。スクラムマスターがいない、あるいは兼任者がPOも兼ねている状態では、判断の責任が宙に浮き、結果として誰かが全部背負うことになります。

理由4：常に全力疾走している感覚。スプリントが終わるとすぐ次のスプリントが始まるため、区切りはあっても休息がないと感じやすい構造です。

実務でできる3つの対処

1. すべてのイベントをタイムボックス化する。デイリーは15分、2週間スプリントならプランニングは最大4時間、レトロスペクティブは1時間半。終了時刻を先に決め、超える議題は別枠に出します
2. 非同期の共有に切り替えられる部分を切り出す。ステータス更新はツール上のカードで完結させ、口頭の場は「止まっているもの」だけに使う。全員が同じボードを見ていれば、集合そのものの必要性が下がります
3. ポイントを評価に使わないことを明文化する。ベロシティは容量を測る道具であり、生産性の成績表ではないという合意をチーム外の管理職とも共有しておく

導入初期に「毎日集まるのが負担」という声が出たチームでは、デイリーの前にボード上で各自が更新を済ませ、集合の場は差分の確認だけに使う形へ移行することで、場の時間と目的が整理されやすくなります。運用の切り替えは、ボードの表示ルールを変えるだけで始められます。

6. 導入前の適性チェック ｜ 自分のプロジェクトに合うか判断する

スクラムはすべての案件に向くわけではありません。次の5問に答えてみてください。

「はい」が3つ以上なら導入の土台があります。一方で、監査対応や法規制で工程ごとの承認証跡が求められる案件、仕様と範囲が契約で固定された請負案件、外部ベンダーへの依存が大きく1スプリント内で検査まで到達できない案件は、無理にスプリントへ押し込まないほうが安全です。その場合は上流を固定型で進め、下流の改善フェーズだけスクラムに切り替えるという分け方が現実的です。

スプリントゴールを具体的に書けるかどうかも判断材料になります。曖昧なゴールはレビューでの合否判定を不可能にするため、SMARTな目標設定の観点で一度書き直してみてください。

7. スクラム運用ツール比較 ｜ チーム規模から選ぶ

なぜツールが成否を分けるのか

スクラムは「透明性」が土台だと述べました。裏を返せば、バックログとスプリントの状態が全員に同じ形で見えていなければ、どれだけイベントを実施しても機能しません。表計算ソフトでも始められますが、更新が誰かの手作業に依存した瞬間に鮮度が落ち、デイリースクラムが口頭の報告会へ戻っていきます。

3つのツールの比較

monday.com・Jira・Trello をスクラム観点で比べる

開発専業の現場ではJira、まず小さく始めたい現場ではTrelloが候補に挙がります。三者はスクラムへの寄り添い方が異なるため、機能数ではなく「誰が毎日触るか」で比べるのが実際的です。

既存のJira運用が回っているなら、無理に移す必要はありません。判断が分かれるのは、企画・デザイン・マーケティングが同じスプリントに乗るチームです。開発者以外がチケットを開かなくなると透明性が崩れるため、非エンジニアでも抵抗なく触れる画面かどうかが実質的な選定基準になります。逆に、バーンダウンやベロシティを標準機能のまま厳密に運用したい開発専業チームであれば、Jiraの厚みが効いてきます。

monday.com の料金プランの見取り図

monday.com は無料プランに加えて有料が4段階あり、スクラム運用で効いてくる機能がどの段階から使えるかを押さえておくと、過剰な契約を避けられます。金額は改定されることがあるため、最新の月額・年払い割引は公式サイトの料金ページで確認してください（年払いにすると月払いより単価が下がる料金体系です）。

20人規模のマーケティングチームでの運用イメージ

広告運用・コンテンツ制作・デザインが同居する20人規模のマーケティングチームを想定します。導入前によくあるのは、週次定例が90分に膨らみ、その大半が各自の口頭報告で消えている状態です。誰が何で止まっているかは、その場に居合わせた人の記憶にしか残りません。

ここでバックログをボード上のユーザーストーリーに移し、「出社後15分以内に各自がステータス列を更新する」というルールを1つだけ足します。すると定例で扱う対象は、ボード上で色が変わっていないカードだけになります。全員分の口頭報告という最大のブロックが消えるため、集合時間は半分前後まで圧縮でき、浮いた時間はレビューでの議論に回せます。

もう1つ変わるのが、スプリント達成率の見え方です。ストーリーポイントの列とダッシュボードのウィジェットを組み合わせると、「引き受けた合計ポイント」と「完了ポイント」が毎日並んで表示されます。3スプリントも回せば、そのチームが実際に消化できる量が数字で出るため、プランニングでの引き受けすぎが自然に減っていきます。削減できる時間の幅はチームによって変わりますが、削れるのは常に「全員の前で口頭報告する時間」だという点は共通しています。

monday.com でスプリントを組む5ステップ

1. バックログ用のボードを作る。1行＝1つのユーザーストーリー。テンプレートから始めても、空のボードに列を足していっても構いません
2. 列を設計する。ステータス、担当者、優先度、ストーリーポイント（数値列）、対象スプリント。この記事のバックログ項目がそのまま行になります
3. スプリントごとにグループを分ける。「今スプリント」「次スプリント」「バックログ」の3グループにしておくと、プランニングは行をドラッグするだけで終わります
4. カンバンビューに切り替える。デイリースクラムはこの画面を映しながら行い、止まっているカードだけを扱います
5. ダッシュボードを追加する。ポイントの合計や完了比率をウィジェットで並べると、スプリント途中でも消化ペースが見えます

自動化も1つだけ入れておくと効果が分かりやすくなります。「ステータスが『ブロック中』に変わったらスクラムマスターに通知」というルールを設定すれば、翌朝のデイリーを待たずに障害へ着手できます。（monday.com の無料プランは2ユーザーまでクレジットカード不要なので、まずボードの形だけ試すことができます。有料機能もプロプランの14日間無料トライアルで確認できます。）

時間軸を使ってリリース計画まで描きたい場合は、ボードをタイムライン表示に切り替えると複数スプリントの並びが一望できます。表示の組み立て方はタイムラインの設計にまとめています。

どれを選ぶか

ドキュメントと仕様が中心で、まずは一人か数人でバックログを形にしたい段階なら、無料プランから始められるNotionが扱いやすい選択です。開発メンバーだけで完結し、ポイント集計やバーンダウンを標準機能で回したいならClickUpが有力です。企画・デザイン・開発が同じスプリントに乗り、経営層にも進捗を見せる必要がある十数人以上のチームであれば、ダッシュボードと権限設定が整ったmonday.comが最も破綻しにくい構成になります。

8. 学びを深める本と資格 ｜ 次に何を読むか決める

まず読む3冊

• 『スクラムガイド』（公式・無料）：本ではありませんが出発点です。20ページ弱でスクラムの定義がすべて書かれており、社内の認識合わせにも使えます
• 『SCRUM BOOT CAMP THE BOOK』：日本のチームがつまずく場面をマンガと解説で追える入門書。導入初期の「これどうする？」に対する答えが並んでいます
• 『アジャイルサムライ』：スクラムに限らず、アジャイルなチームの立ち上げ方を扱う定番。インセプションデッキなど、プロジェクト開始時に使える道具が具体的です

さらに実務を深めたい人には、プロダクトオーナー向けの優先順位付けや、ユーザーストーリーの書き方を扱った書籍を次の一冊に選ぶとつながりが良くなります。

認定資格とキャリア

代表的なのはScrum.orgが提供するPSM（Professional Scrum Master）と、Scrum Allianceが提供するCSM（Certified ScrumMaster）です。PSMは試験のみで受験でき、CSMは所定の研修受講が前提になります。独学で知識を確認したいならPSM、チームでの実践演習を重視するならCSM、という選び分けが一般的です。

資格そのものが年収を保証するわけではありませんが、スクラムマスターやアジャイルコーチの求人では要件に挙げられることがあり、社内で役割を任される際の説明材料にはなります。報酬水準は企業規模や地域で幅があるため、求人情報で最新の条件を確認してください。

まとめ

• スクラム開発は、1〜4週間のスプリントを繰り返し、透明性・検査・適応の3本柱で計画を調整するアジャイルのフレームワーク。アジャイルと対立する概念ではなく、その具体的な実装です
• 役割はプロダクトオーナー（何を作るかを決める）、スクラムマスター（妨害を取り除く）、開発者（どう作るかを決める）の3つ。優先順位の決定者は必ず一人に絞ります
• 流れはバックログ作成→プランニング→スプリント実行とデイリースクラム→レビュー→レトロスペクティブの5ステップ。Tryを次スプリントの作業として登録するまでが振り返りです
• 「つらい」と感じる原因は会議の積み上がり、見積もりの約束化、役割の曖昧さ。タイムボックス化・非同期共有・ポイントを評価に使わない合意の3点で解消できます
• 向くのは要件が動き、部分的に価値を届けられる案件。承認証跡が求められる案件は上流固定・下流スクラムのハイブリッドが安全です

この記事のStep1で挙げたユーザーストーリー形式の項目を、そのままボードの1行として書き出してみてください。列にステータス・担当者・ストーリーポイント・対象スプリントを足し、「今スプリント」「次スプリント」「バックログ」の3グループに分ければ、最初のスプリントバックログが完成します。あわせて【保存版】チェックリストをコピーしておけば、最初のスプリントから各イベントの締め方まで固まります。monday.com なら列の追加もグループ分けも画面操作だけで済み、無料プランは2ユーザーまでクレジットカード不要で試せます。

よくある質問

スクラム開発とアジャイル開発の違いは何ですか？

アジャイル開発は「変化に対応しながら価値を早く届ける」という価値観と原則の総称で、スクラムはその原則を役割・イベント・成果物として具体化したフレームワークです。両者は選択肢として並ぶものではなく、スクラムを実践していればアジャイル開発をしていることになります。対比すべき相手は、要件を固めてから工程を順に進めるウォーターフォール型です。

スクラム開発は本当にきついですか？

きつくなる原因は、フレームワーク自体よりも運用の設計にあります。イベントを足し算で導入して実装時間が削られる、ストーリーポイントが外部への納期コミットや評価指標に転用される、役割の境界が曖昧で判断責任が宙に浮く——この3点が典型です。すべてのイベントに終了時刻を先に決め、ステータス更新を非同期のボード上で完結させるだけでも、負荷感はかなり下がります。

スクラムマスターの年収やキャリアはどうなりますか？

報酬水準は企業規模・地域・兼任の有無で幅が大きく、一律の目安を示すのは適切ではありません。求人情報で最新の条件を確認してください。キャリアパスとしては、複数チームを支援するアジャイルコーチ、プロダクトオーナー、開発マネージャーへ進む例が多く見られます。PSMやCSMなどの認定資格は、社内で役割を任される際の説明材料になります。

アジャイル開発はもう時代遅れですか？

時代遅れになっているのは手法ではなく、イベントだけをなぞる形骸化した運用です。毎日集まるが問題は解決されない、振り返りをするが何も変わらない、という状態が「アジャイル疲れ」の正体です。仕様が短期間で変わる状況では、短いサイクルで方向を修正できる進め方の価値はむしろ高まっています。

スクラムは何人くらいのチームに向きますか？

開発者はおおむね3〜9人が目安です。3人未満だとスキルの偏りで自己完結できず、10人を超えるとデイリースクラムが15分で終わらなくなります。人数が増える場合は、プロダクト単位で複数のスクラムチームに分割し、各チームにPOとスクラムマスターを配置する形を検討してください。

導入の第一歩は何から始めればいいですか？

バックログを一列に並べることから始めてください。やりたいことを機能名ではなくユーザーストーリー形式で書き出し、優先順位を付けて上から並べる。この一覧がないとプランニングが成立しません。並べ終わったら、まず2週間のスプリントを1回だけ試し、レトロスペクティブで自分たちに合う長さを決め直すのが安全です。

専任のスクラムマスターがいなくても運用できますか？

兼任でも運用は可能です。ただし兼任者が開発者の作業を割り振り始めると自己管理型が崩れるため、「進行の妨げを取り除く役割であって、割り振りはしない」という線引きを最初にチームで合意してください。プロダクトオーナーとの兼任は、作る側と優先順位を決める側が同一になり検査の視点が働かなくなるため避けるのが無難です。

スクラムとウォーターフォールを混ぜて使えますか？

現実的な選択肢です。要件定義や基本設計など、承認証跡が求められる上流工程を従来型で固め、実装以降の改善サイクルをスクラムで回す分け方がよく採られます。重要なのは、どこからがスプリントの対象範囲かを最初に明文化し、上流の変更が入ったときの扱い方を決めておくことです。