コンテンツにスキップ
Scrum Knowledge Graph

スプリント (Sprint)

概要

Section titled “概要”

スプリントとは、自己組織化されたスクラムチームが要求やアイデアを「完成」した価値あるインクリメントへと反復的に変換するための、1か月以内の固定期間（タイムボックス）によるコンテナイベントである。スクラムの「鼓動」として計画、開発、検査、適応を内包し、継続的フィードバックと予測可能性をもたらす。機能開発のみならず、アーキテクチャ上の不確実性を低減する仮説検証や技術計画活動を反復内に組み込む枠組みとしても機能する。大規模環境では複数チームの期間同期を通じて依存関係の調整や継続的統合の基盤となり、組織的統制とチームの自律性の均衡を保つ。一方で、実務では未完了タスクの発生や会議負荷の増大といった調整上の課題も生じる。

詳細

Section titled “詳細”

  • 一貫性・期間とプロジェクトとしての性質：スプリントは、自己組織化されたスクラムチームが外部の干渉を受けずに特定の機能を自律的に開発するために設定されるタイムボックス化された反復期間である[1]。1か月以内（通常1〜4週間、事例によっては2〜3週間や2週間から4週間）の固定期間（タイムボックス）として設定される開発単位であり、プロジェクト開始時に設定された後は途中で変更されず一貫性が保持されるとともに、前のスプリントが終了すると直ちに新しいスプリントが開始される[2][3][4][5][6][7][8][9][10][11][12][13]。スクラムの「鼓動」として一貫したケイデンス（リズム）を提供し、スクラムチームが作業にコミットして集中と安定性、持続可能なペースを維持するための基盤となり、短期目標の設定によるモチベーション維持、デリバリーの予測可能性向上や頻繁なフィードバックループの獲得に貢献するとともに、開発チームが一定のペースで製品開発を反復的に進めるための時間枠として機能する[9][10][11][14][15]。1か月以内の短期間のプロジェクトとして捉えることもでき、定義や設計、計画、実際の開発作業、最終成果物の作成が含まれる[5]。スケジュール定義に基づくイテレーションとして成果物を具体的な形とし[16]、短サイクルの反復開発を通じて顧客との距離を縮め、要件変更や開発に柔軟に対応する[17][18][19]。期間設定は1〜4週間や1週間〜1ヶ月間等に設定され[12][11][20]、2〜3週間の固定期間や2週間単位を採用する実践例や[13]、約7営業日単位で運用される実践例もある[21]。実態調査においても、「スプリントが長すぎる」（重み付けスコア6.55%）や「スプリントの長さのばらつき」（同10.12%）といった期間設定に関する反パターンはスコアが最も低い部類であり（満点168に対する割合で、組織の割合ではない）、固定期間の遵守というガイドラインは広く定着していることが示されている[22]。

  • 位置づけと含まれるイベント：スプリントはスクラムの中心的な要素および基本的な開発単位であり、プロダクトビジョンを実現しプロダクトゴール達成に必要なあらゆる作業やアイデアを価値に変換するための容器（コンテナ）として機能し、他すべてのイベントや開発作業を内包する[4][6][7][8][14][23][9][10]。セキュリティを考慮したアジャイル開発においても、進捗管理や最適化を行うための基本的な活動単位として機能する[18]。スプリント期間に合わせて開発者のタスクが設計・実行され[18]、実装やテストなどの各フェーズがスプリント単位で反復的かつ継続的に実行される[23]。各スプリントの開始時にはスプリントプランニング（計画）が行われ、期間中にはデイリースクラムや開発作業が実施され、終了時にはスプリントレビューとスプリントレトロスペクティブ（改善）が実施される[2][3][4][5][6][7][14][19][12][20][24]。スプリント内では計画、実行、検査、適応の一連の活動が行われ[20]、チームはスプリント期間全体を通してプロセスの検査と適応の機会を利用し、ジャストインタイムで意思決定を行う[25]。スプリント内に完了しなかったタスクについては、レトロスペクティブの段階で原因分析が行われる[18]。初期の定義ではスプリントプランニングが「スプリント計画ミーティング」と表記されていた[2][4]。また、プロダクトバックログリファインメントを内包イベントとする定義や[8]、スプリントの終わりにプランニングを行ったりする独自手順も報告されている[18]。スケーリングされた大枠のフレームワークにおいては、一連のイベントサイクルの締めくくりとしてNexusスプリントレトロスペクティブをもって終了する形式も定義されている[26]。

  • インクリメントの創出・デリバリーと評価：各スプリントを通じてスクラムチームは選択されたプロダクトバックログアイテムの達成へ取り組み[20]、開発およびテストを行って、毎スプリントの終了時に少なくとも1つの「完成（完了）」した動作可能・出荷可能で顧客への提供やリリースが可能なプロダクトインクリメント（新機能を含む）を構築・デリバリーする[4][5][6][9][10][20][11][12][13][14]。この反復的かつインクリメンタルなサイクルにより、製品への継続的な価値提供が可能となる[23]。単一のスプリント内であっても複数のインクリメントを作成し、早期にリリース可能である[9]。成果物は反復的・漸進的に構築・テストされ、出荷可能な状態でデリバリーされる[14][12][11][13][10]。スプリント終了時は、成果や進捗がスコア等によって評価され、チームのパフォーマンス最適化に活用されるケースもある[18]。カンバンのプラクティスを組み合わせる場合を含め、価値のデリバリーはスプリント単位で1回に限らず期間中複数回行うことが推奨されており、ワークフローやフロー指標を活用した意思決定が行われる[25]。さらに、チームの応答性を測る重要な評価指標として、スプリントの大部分においてステークホルダーやエンドユーザーへ提供可能なインクリメントを生み出せているかが位置付けられている[27]。

  • 変更・品質の制限とスコープの再交渉：スプリントではスプリントゴールを設定し、その達成に向けた開発活動や進捗状況を日々管理する[10]。スプリント期間を通じて明確なスプリントゴールを設定し、ステークホルダーとの密接な協調を維持することは、チームの有効性を高める要因となる[27]。期間中はスプリントゴールの達成を阻害・危険に晒すような変更は認められず、チーム構成や品質目標（インクリメントの品質）を低下させない[2][3][4][5][6][7][8][9]。一方で、開発の進行に伴う学習の深化とスコープの明確化に応じて、プロダクトオーナーと開発者の間でスコープの再交渉が行われることもある[5][8]。これらによりチームは完成の定義に基づく成果物へのコミットメントを保持する[9]。

  • リスク管理と中止（キャンセル）条件：スプリント期間を短く設定することで学習サイクルが増加し、開発対象の変更や複雑化、リスクの増大を抑制・管理できる[4][5][8][9]。オープンなフィードバックを通じてコストや労力のリスクを一定範囲に限定したリスク管理も可能となる[8][9]。会社の方向性や技術状況の変化、あるいはゴールが不適切となった（もはや役に立たなくなった・陳腐化・失効した）場合、プロダクトオーナーの権限（判断）によってのみ途中で中止（キャンセル）できる[2][3][4][5][6][28][7][8][9]。ただし、大規模フレームワークの比較においては、Nexusでも同様にプロダクトオーナーに中止権限が認められている一方、LeSSでは開発チーム側も前倒しでスプリントを終了させる権限を持つとされるなど、権限の所在に差異がある[29]。

  • 技術的・概念的拡張（オントロジー・ブロックチェーン・セキュリティ）：スクラム参照オントロジーにおいては核心的な重要概念の一つとして位置付けられており、開発ツールや各アプリケーションから統合されるデータにコンテキストを与え、意味的に統合するための基礎的な表現単位として機能するとともに、データ駆動型意思決定の枠組みを提供する[17]。ブロックチェーン統合型手法（ChainAgile）では、スプリント単位でバックログを管理し、計画されたユーザーストーリーやタスクが設計、開発、テスト、デプロイのサイクルを順次通過する[24]。あわせて、進行状況および成果物の状態は不変の台帳に記録・追跡され、プロジェクト全体の正確な進捗管理と検証・決済を実現する仕組みが構築される[24]。さらに、セキュリティを重視したアジャイル開発アプローチにおいても、セキュリティ要件の組み込みと進捗最適化を両立させる基礎単位としてスプリントが適用される[18]。

  • アーキテクチャの不確実性管理と仮説エンジニアリング：ミッションクリティカルな開発プロジェクトにおいて、機能開発と並行してアーキテクチャ上の不確実性を管理するためにスプリントを活用する手法（ArchHypo等）が提案されている[21]。このアプローチでは、プロジェクト開始前に「Sprint-0」開始ミーティングを実施してバックログ項目の共有や初期仮説の設定する[21]。本開発期間中は約7営業日単位のスプリントが複数回（計6回など）実施され、各スプリントの開始時にアーキテクチャ関連タスクを含むバックログアイテムの優先順位付けが行われる[21]。高い不確実性や影響度を持つ仮説に対処するための技術計画活動を単一のフェーズに固めず、各スプリントに分散して計画・実行することで、事前のアーキテクチャ設計を避けながら不確実性を下げていく運用がなされる[21]。

  • 他手法との比較・連携およびスケーリング：タイムボックス型スプリントは、継続的にタスクを引き込むカンバンのプル型フローと対照的であるとされることもあるものの[16]、カンバンの補完的なプラクティスを導入した場合でもスプリントが置き換わることはなく維持され、プロダクトやプロセスの検査・適応の基本枠組みとして機能する[25]。また、モデルベースシステムエンジニアリング（MBSE）とスクラムの融合（sMBSAP等）においては、スプリント（イテレーション）ごとに要求やシステムモデルの動的な進化に応じて、継続的なトレーサビリティを維持する仕組みが提供される[23]。デザインベース研究（DBR）の評価イテレーションとスクラムのスプリントを同期させ、2〜3スプリントごとに詳細な形成評価を実施する手法も存在する[13]。大規模開発ではNexusやScrum@Scaleにより複数チームが同一スプリントで同期し統合インクリメントを構築する[26][10]。その際、スプリントの期間や基本ルールはスクラムガイドの規定がそのまま継承される[26]。さらに、大規模アジャイル変革における成功要因の一つとしても短いイテレーション（スプリント）の実施が挙げられており、短いサイクルで開発を反復することにより、大規模環境においても開発プロセスの適応を促進し、進捗の可視化や迅速なフィードバックの獲得、プロジェクトの成功を後押しすることが示されている[30][31]。

  • LeSSなどのスケーリングアプローチでも、複数チームが同一のタイミングでスプリントを開始・終了し、共有されたスプリント計画、レビュー、レトロスペクティブを実施する運用が採られる[27][32]。共通のイテレーション境界を持つことで、クロスチームでの依存関係の調整や統合、リリース管理の計画が容易になる利点がある[32]。その一方で、スプリントという共通のタイムボックスによる統制の下であっても、チーム内部における日々のタスク管理（スクラムボードやカンバンボードの利用形態など）は各チームの判断で進めることができ、組織的統制とチームの自律性のバランスが図られる[32]。

  • スケーリングフレームワークにおける意思決定権限とチームの自律性：大規模アジャイルスケーリングフレームワークにおけるスプリントの分析では、実行フェーズにおける意思決定スタイルの制約やチームの自律性の範囲が議論されている[29]。スプリント実行中は開発が進行中であるため、計画フェーズと比較して意思決定スタイルの多様性が制限され、自律性が狭まる傾向がある[29]。また、スプリントゴールの設定について、単一スクラムではチーム全体でゴールを決定するが、Nexusでは各チーム代表者とプロダクトオーナーが決定し、LeSSではプロダクトオーナーが事前設定したゴールに開発チームが変更を加えるなど、フレームワークごとに決定権の所在が異なる[29]。資産や活動の調整においては、スプリント中のタスク配分はチーム主導で行われるものの、SAFeではスプリント中のバックログ調整やチームメンバーによるプロダクト資産の直接修正（集団所有）が明示されている[29]。

  • ユーザー中心設計・リーンスタートアップとの統合と有機的適応：スプリントは一定期間で区切られた開発サイクルとしてチームに安定したリズムと作業テンポを提供する[33]。スクラムからエクストリーム・プログラミング（XP）や統合アプローチへと移行する過程においては、「スプリント」という呼称が「反復（イテレーション）」へと変更されたり、計画や見直しの頻度が柔軟に調整されたりする運用の変化が見られる[33]。また、スプリント等の反復期間の中で仮説検証のための実験や「構築 - 計測 - 学習（Build-Measure-Learn）」サイクルを実行し、迅速な軌道修正（ピボット）を行う統合的実践も行われる[33]。反復の途中で問題の定義が不十分であると判明した場合には、初期の探索フェーズに戻るなど、固定的な枠組みにとらわれない有機的で柔軟な運用が重視される場合もある[33]。

  • 教育環境（eduScrum）への応用：反転授業などの教育現場におけるeduScrumの実践においても、スプリントは学習プロセスを一定期間ごとに区切り、短期的な成果の提出期限として機能する反復作業期間として位置付けられる[34]。オンライン学習プラットフォーム（OPAL等）上の構成要素として設定され、スプリントで得られた成果物をアップロードして議論や検証に供する運用が行われる[34]。これにより、学習の進捗を可視化し、高品質な成果物を段階的に生み出すためのタイムボックスとして機能するとともに、協調学習の促進と成果の継続的な確認を支える役割を果たす[34]。

  • 大規模展開におけるスプリント運用の課題：大規模ソフトウェア開発におけるスプリントの実装では、複数チーム間における調整の複雑化に伴い以下のような課題が生じることが報告されている[1][15]。

    • 開発サイクルの差異による待ち時間：あるチームが割り当てられた作業を完了しても、依存関係にある別チームのスプリントが完了していない場合、作業成果物が待機状態となり全体の進行が遅延する[1]。
    • スプリント期間の不一致：チームによってスプリント期間（例えば2週間と1か月）や開始・終了のタイミングが異なると、チーム間でのテスト活動や機能統合の整合性を取ることが困難になる[1]。
    • 機能間の依存関係の発生：各チームがスプリント内で開発する機能を自律的に選択する際、他チームの計画と調整がなされていないと望ましくない結合やブロッカーが生じる[1]。
    • 最適なスプリント数の見積もり：リリース計画において、製品を納品するまでに必要な反復（スプリント）の最適回数を特定することが困難であるとされる[1]。
    • また、追加のステークホルダーの関与ニーズをすべて満たそうとすると、通常のスプリントイベントの範囲と意図が拡大し、会議運営の負荷が増大するリスクが指摘されている[15]。

  • 実務におけるテイラリングと影響：スプリントは規範的な定義上、明確な期間設定を求められ、最もテイラリング（カスタマイズ）の頻度が少ないプラクティスとされる一方、実際の現場ではプロジェクトの文脈に応じた独自のテイラリングが選択されることもある[35]。具体的状況として、固定のタイムボックスを設定せずタスクの完了状況に応じて最大20稼働日など柔軟に期間を延長する運用、1か月を超える長期スプリントの設定、あるいはスプリント自体を導入せず従来の工程管理と併用して開発を進める事例が報告されている[35]。しかし、このようにタイムボックスを曖昧化したり無制限にスプリントを延長したりする運用は、チームメンバーのゴールに対するコミットメント低下やモチベーション低下を引き起こすリスクがある[35]。一方で、フィールド研究等のスケジュールの揺らぎや遅延に対応するため、カンバンの要素を取り入れた柔軟な運用（スクラムバン）やバッファースプリントが活用される事例も見られる[13]。

  • 運用上の反パターンと実態：スプリントの期間自体の設定は遵守される傾向が強い一方で、実務運用ではスプリント内での完了や品質検証に関する深刻な反パターンが広く確認されている[22]。「未完了のタスク」は、調査された反パターンの中で重み付けスコアが最も高い（70.24%、満点168に対する割合）[22]。「決してない」と答えた回答者はおらず、「まれに」は3人であった[22]。さらに、「次のスプリントでのテスト」も重み付けスコアが50.60%（満点168に対する割合）で上位にあり、スプリント期間内に完成したインクリメントを構築できず、品質保証活動が次期サイクルへ持ち越される状況が示唆されている[22]。

アジャイル手法ではプロジェクトを小さな反復（イテレーション）に分割し、頻繁なリリースとフィードバックループを可能にする[36]。

スプリントは、短い時間間隔で高品質なソフトウェアプロダクトを提供するための反復的な開発サイクルである[37]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Sprint Scrum Event Iteration Scrum Core Timebox Events
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • E3 [警告] (Sprint): スプリントは、承認された成果物(AcceptedDeliverable)を含んだインクリメントを生成するべきです。リリース可能な価値を生み出せていない状態が続くと市場への応答性が低下します（Verwijs & Russo, 2022）。
  • S4 (Sprint): スプリントは必ず1つのスプリントバックログを保持しなければなりません。
  • S8 (Sprint): スプリントは正確に1つのスプリントプランニングを含まなければなりません。
  • S8 (Sprint): スプリントは正確に1つのスプリントレビューを含まなければなりません。文献(Özkan & Özcan-Top, 2022)によれば、レビューの省略や不完全な参加者は、頻繁なフィードバックの機会を奪い、結果的に遅い段階での大きな手戻りを引き起こします。複数回記録されている場合は、省略ではなく分割開催（例: Epic単位の前倒しレビュー）の可能性があるため、開催意図を確認してください。
  • S8 (Sprint): スプリントは正確に1つのスプリントレトロスペクティブを含まなければなりません。スプリントレトロスペクティブを行わない、まれにしか行わない、または15分程度で終えるテーラリングが報告されています。時間が短いと効率的な議論ができず、実行可能な改善項目を特定できないこと、レトロスペクティブを短くしすぎたり行わなかったりしたチームは継続的改善の段階を持てなかったことが述べられています（Özkan & Özcan-Top, 2022）。
  • S8 (Sprint): スプリントは少なくとも1つ以上のデイリースクラムを含まなければなりません。

関連する用語

Section titled “関連する用語”

脚注

Section titled “脚注”

  1. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5

  3. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4

  4. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  6. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. Scrum Guide 2020 — 「スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  8. Scrum Guide (LeSS Version)（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  9. Scrum Guide Expansion Pack — 「スプリントで働くことは、スクラムチームが明確で短期的なゴールに集中するための一貫したリズムを提供する。」「時間の経過とともに、持続可能なデリバリーペースを構築し、予測可能性を向上させ、継続的改善を促進する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  10. Scrum@Scale Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  11. Scrum: An Agile Software Development Process and Metrics — 「スプリントとは、製品開発の過程においてチームが作業することをコミットする固定の期間を指します。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  12. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  13. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  14. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  15. Dependencies of Agile Teams – An Analysis of the Scaled Agile Framework（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  16. Integrating DAST in Kanban and CI/CD: A Real-World Security Case Study（ライセンス: CC BY 4.0） ↩ ↩2

  17. An Ontology-based Approach to Enable Data-driven Decision-making in Agile Software Organizations（ライセンス: CC BY 4.0） ↩ ↩2

  18. Agile Software Development with Secure and Scrum-Centric Approach（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  19. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered — 「スクラムは、プロダクトバックログやスプリントバックログといった主要な作成物（アーティファクト）と、デイリースクラム、スプリント計画（Sprint Planning）、スプリントレビュー（Sprint Review）、スプリントレトロスペクティブ（Sprint Retrospective）などの定期的なイベントで構成されています。」（原文: “Scrum consists of key artifacts such as the Product Backlog and Sprint Backlog, as well as regular ceremonies including the Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  20. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  21. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「2022年6月1日、チームはそれぞれ7営業日続くプロジェクトのスプリントを開始した。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  22. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations — 「スプリント計画は、スプリントで取り組むべき作業を決定するプロセスです。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  23. Integration of MBSE and scrum for complex system development: the sMBSAP proposal（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  24. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  25. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  26. Nexus Guide — 「Nexus のスプリントは、スクラムのスプリントと同じである。」「Nexus のスクラムチームは、1 つの統合インクリメントを開発する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  27. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches — 「その下位プロセスには、ステークホルダーとのコラボレーション、共有されたゴール、スプリントレビューの質、価値などが含まれる。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  28. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩

  29. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「スクラムはスプリントがどのように行われるべきかを明確に定義しています。」（原文: “Scrum clearly defines how a sprint should occur.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  30. Agile Transformation at Scale: A Tertiary Study（ライセンス: CC BY 4.0） ↩

  31. Evolution of the Agile Scaling Frameworks（ライセンス: CC BY 4.0） ↩

  32. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  33. Combining User-Centered Design and Lean Startup with Agile Software Development: A Case Study of Two Agile Teams（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  34. An Implementation and Evaluation Report of the Active Learning Method EduScrum in Flipped Class（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  35. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「スプリント、スプリントレトロスペクティブ、デイリースクラム、スプリントレビュー、およびスプリントプランニングミーティングは、本研究においてテーラリングされていることが判明した5つのスクラムプラクティスである。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  36. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「プロジェクトを小さな反復（イテレーション）に分割し、頻繁なリリースとフィードバックループを可能にすること。」（訳）（ライセンス: CC BY 4.0） ↩

  37. Scrum: A Systematic Literature Review — 「スクラムは、スプリントとして知られる短い時間間隔で高品質のソフトウェアプロダクトを提供するために、Easel CorporationのJeffrey Sutherlandによって1993年に開発された [35]。」（訳）（ライセンス: CC BY 4.0） ↩