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

デイリースクラム (Daily Scrum)

概要

Section titled “概要”

デイリースクラムは、開発者がスプリントゴール達成に向けて日々の進捗を検査し、次の24時間の計画を調整・適応するための15分間の日次イベントである。原則として毎日同じ時間・場所で開催され、集団的な進捗や直面する障害を同期して作業の重複を防ぐ持続的な協調メカニズムとして機能する。チームの成熟に伴い自発的な連携へ進化するほか、大規模環境における依存関係の早期把握やビジネス側との協働理解にも活用される。一方で、参加者増加による形骸化や技術的議論による時間超過といった課題も生じやすく、反復的な学習プロセスの中で短時間に効果的な同期と認識共有を図るプロセスの規律と自律性の維持が重要となる。

詳細

Section titled “詳細”

  • 位置付けと目的： デイリースクラム（デイリーミーティング・デイリースタンドアップ・スクラムミーティング等とも称される）は、自律的なチームが日々の活動の速度を合わせ（同期し）、次の24時間の計画を作成するためにスプリント期間中毎日開催される15分間の定例内部イベントである[1][2][3][4][5][6][7][8][9][10][11][12]。本イベントの目的は、スプリントゴールを達成するインクリメントの提供に向け、スプリントゴールとスプリントバックログの進捗を検査することにある[13]。あわせて、進行上の障害物を特定して残作業を評価し、実行可能な作業計画を作成・適応することでゴール達成の可能性を最適化する[2][7][8][9][13][10][14][11][15]。反復的な学習プロセスにおいて、集団的な進捗状況をリアルタイムで共有してチームの集中を維持し、発生した障害やボトルネックを迅速に検知・調整する持続的な協調メカニズムとしても機能する[16]。さらに、メンバー間で共有された認識を維持することで、作業の重複や依存関係の不整合を回避する役割を果たす[16]。各チーム内で制限時間を設けて実施されることで、メンバー間の連携と進捗の自己組織的な調整を可能にする基本実践でもある[17]。単なる管理者への進捗報告会ではなく、チーム自身のための共有・計画ミーティングであり、チームに集中・一体感・緊迫感をもたらし[14]、チームのコラボレーションとパフォーマンスを最適化する[12]。さらに、チーム内の心理的安全性を基盤とした質の高い対話と相互サポートを促すとともに[2]、コミュニケーションの改善・他の不要なミーティングの排除・障害やリスクの迅速な特定と排除・意思決定の迅速化を助長し、作業計画を微調整する検査と適応（セルフマネジメント）の場として機能する[18][7][8][9][4][6][14][12][15][13][10]。また、日常的な直接対話を通じてメンバー間の情報共有を円滑にし、問題の早期発見と協調的な解決を支援するとともに、形式的・非公式な双方のコミュニケーションを活性化して相互の信頼関係を深め、同僚支援（ピアサポート）を促進する[19]。これにより、チーム内の高い結束とコミュニケーションの透明性が生み出され、心理的安全性や公平性の認識向上にも寄与する[19]。さらに、組織のビジネスチームがアジャイル開発の考え方を実践し、技術チームの働き方を理解するための基本プラクティスとしても位置づけられている[20]。

  • 対象者と役割責任・開催責任： 主に開発者（開発チーム）のためのイベントであり、通常はプロダクト開発者のみで実施される[7][8][10][14][9][21][13][3]。2009年版および2010年版では「チーム」に責任があり[18][7]、特に2010年版ではスクラムマスターがミーティングを15分以内に収めるよう管理し、コミットされたチームメンバー（豚）以外の参加者（ニワトリ）の発言を制限する規則が適用されていた[7]。一方で、スクラムマスターを含めたスクラムチーム全体が主体となって進捗確認を行う運用として整理する文献もある[4]。

  • 実施形式とタイムボックス： プロセスの複雑さを避けて習慣化を促すため、スプリント期間中は原則として毎日、同じ時間かつ同じ場所で開催される最大15分（15分以下）のタイムボックスイベントである[7][8][9][13][10][14][11][12][6]。公式スクラムガイド等では厳格な15分間のタイムボックス型イベントとして位置づけられている[10][6]。短時間で効率的に進めるため、通常は立って円陣を組むなどして実施される[3][4][5]。実施頻度に関して、多くのガイドや文献では「毎日（日次）」とされるが[2][12][3][4][6][14][7][8][9][13][10][11]、毎勤務日（every working day）と表現される場合もある[15]。適切なオープンスペースが確保できない環境では、廊下などで実施せざるを得ず通行人による中断が頻発するといった問題が生じるが、専用スペースの確保によって円滑な進行が可能となる事例が報告されている[22]。

  • アジェンダと進め方： スプリントゴールに対する進捗に焦点を当て、前回のイベントからの作業（完了した作業・成果）を検査・検証しつつ、メンバー間で取り組みの状況をリアルタイムに最新化し、次回（次の24時間・本日）までに行う実行可能な作業計画を予測・作成する[2][7][8][9][13][10][11][15][12]。具体的には、選択されたユーザーストーリーやシナリオの実装に向けてその日に実行する作業を計画・調整し[12]、チーム内で進捗状況を共有するとともに、進行上の問題や障害（ブロッカー）、他者への助けを早期に開示して手戻りや遅延を防ぐ[2][12][6]。従来の標準的な形式では、「前回（昨日）完了したこと」「次回（本日）行う予定の作業」「直面している障害や問題点」という3つの質問に各メンバーが回答・共有する運用が定義・実践されていた[18][7][8][9][3][4][6]。これに対し、質問形式に限定せず、スプリントゴールに向けた質問や議論をベースに開発者自らが形式を柔軟に設定して進める方式も明示されている[13][10]。進行においては、稼働していない人ではなく停滞している作業を監視し、進行中の作業を少なく抑えて仕掛かりを完了させる行動が促進される[14]。なお、詳細な議論や再計画が必要な場合は、デイリースクラムの直後などに別途実施されるほか、イベントの時間外であっても一日を通じて頻繁に対話し計画の調整が行われる[8][9][14][15]。カンバンを併用するフローベースの運用では、カンバンボードを囲み、仕掛中の作業（WIP）制限の遵守状況や、ブロックされた作業項目の特定・解除方法の検討、進行中作業の年齢（Work Item Age）やサービスレベル期待値（SLE）違反状況の確認、当日の作業完了を阻害する要因の点検等を通じて価値のフロー最適化と計画調整する[23][14]。また、デザインベース研究を取り入れた運用では、通常のソフトウェア開発タスクの進捗確認に加え、ユーザー評価から得られた質的フィードバックや研究上の問いに関する省察（リフレクション）がアジェンダに組み込まれる[5]。さらに、スプリント中盤のチェックポイント設定やアクセシビリティ専門家との協議などを組み合わせることで、チーム全体の方向性とユーザーニーズとの整合性を高めるアプローチも実践されている[5]。

  • チームの成熟度とプロセスの規律・課題解決の進化： 発言時間の制限などを通じて無関係な議論を排除し、当日の重要事項や優先順位に集中するプロセスの規律を養う場として機能する[24]。未熟なチームでは定例イベントの中でのみ問題を共有する傾向があるが、成熟が進むと日常的に即座に相談し合う自発的な行動様式へと発展する[24]。さらに、各自が直面している課題を共有することで、チーム内や外部のどの専門家が支援できるかを即座に特定・連携する相互支援とネットワーク活用の基盤となる[24]。

  • 大規模環境（スケール環境）における拡張関係： デイリースクラムはこうした軽量なスケーリング手法の直接的な基盤として広く採用されており、日常的なコミュニケーションとアジリティの維持に寄与する[17]。実際の現場でも、開発チーム内の日常的な同期に加えて、チームリーダーや関係者が集まる「チーム間スタンドアップ会議」を設置し、チームをまたぐ依存関係の管理に活用される事例がある[22][20][17]。

    • Nexus環境: 各スクラムチームの代表者が「Nexusデイリースクラム」に参加して統合インクリメントの現状やNexusスプリントゴールの進捗を検査し、統合上の問題や新たに判明した依存関係・影響を特定する[25][11]。個別のスクラムチームのデイリースクラムはNexusデイリースクラムを補完する役割を持ち、そこで提起された問題を考慮した上でその日のチーム計画を立てる[25][26]。さらに、イベントのタイムボックス内に限らず、必要に応じて一日を通じてチーム間での調整や再計画の議論が行われる[25]。
    • スケーリングフレームワークにおける意思決定と自律性: 各フレームワークにおける意思決定の構造や自律性の位置づけには差異が分析されている[26]。LeSS（大規模スクラム）では、開発チーム全体が自チームのデイリースクラムの実施方法を自律的に決定できる権限を持つ[26]。これに対しScrum@Scaleでは、スプリントチームの代表者がスケールドデイリースクラムの参加者を決定し、その選定では独裁的、協議的、合意形成など多様な意思決定スタイルを用いる実態がある[26]。
    • 大規模環境における課題と継続的適応: 大規模開発におけるデイリースクラムの運用には固有の課題も報告されている[27]。チーム規模や参加人数の増大に伴って全員を招集した際に適切な詳細レベルで議論を維持することが困難になり、会議の肥大化と非効率化を招く傾向が指摘されている[27][22]。また、高頻度かつ長引くスタンドアップミーティングは開発作業そのものを圧迫し、貴重な時間を奪う無駄と捉えられることがある[27][22]。 さらに、大規模アジャイル開発の現場における運用実態として、プロダクトオーナーやマネジメントからの要請に基づき1日1回の必須プロセスとして位置づけられる運用が見られる[28]。その一方で、プロダクトオーナーが同席することにより、他チームとの依存関係や外部の専門家との調整が必要な課題を早期に検知してチーム外と接続できる利点も報告されている[28]。

  • プロジェクトに応じたテイラリングおよびリモート環境における課題： 文脈やドメイン、運用環境に応じたテイラリングが行われる[29][5][6]。系統的文献レビュー（SLR）分析によると、デイリースクラムはスクラムのプラクティスの中で2番目にテイラリング頻度が高いとされる[29]。

    • 頻度の変更：時差対応を要する分散開発においてオンショアチームとオフショアチームが別々にデイリースクラムを開催する運用や、1日複数回の開催、共有事項の少なさによる2日に1回や週1回への削減[29]。
    • タイムボックスの変更：15分を超えて30分程度開催するアプローチが存在するが、長時間のミーティングはチームメンバーの疲労や集中力欠如につながる[29]。
    • 参加者の変更：外部ステークホルダーをミーティングに参加させる運用[29]。 また、リモート環境では、メンバー間の相互作用が低下し、能動的な再計画の場から単なる進捗報告セッションへと形骸化しやすい課題や会議の長期化によるメンバーの疲労といった傾向が指摘されている[6]。こうした課題への対策として、厳格なタイムボックス制限の適用や、Slack等の非同期ツール・デジタルボードを併用した運用の組み合わせが推奨されている[6]。同じ Action Research の行動計画では、デイリースクラムの最後にスクラムマスターが共有された重要な情報を要約し、全員が理解したかを確認することも取り決められた[30]。

  • 運用の実態とアンチパターン： デイリースクラムは進捗報告および翌日の作業計画の同期に特化し、15分以内で実施することが推奨されているが、現場の実態調査ではいくつかの反パターンが確認されている[31]。「デイリースクラムが毎日開催されない」（重み付けスコア12.50%）や「固定された時間帯に開催されない」（同7.14%）といった反パターンは、スコアが低い（満点168に対する割合で、組織の割合ではない）[31]。毎日固定された時間帯に開催する習慣自体は組織に広く定着している[31]。その一方で、「デイリースクラムが15分を超えてしまう」反パターンは、表IXの重み付けスコア（満点168に対する割合）が61.31%で2位である[31]。23人の回答者が「頻繁に」「常に」発生すると答え、「決してない」は1人であった[31]。この時間超過の主な要因として、本来の目的である進捗と計画の同期を超えて、技術的な問題解決などの議論を会議内で長々と実施してしまう傾向が挙げられている[31]。

リモートワークへのスクラム実践の適応を扱った、9 人のスクラムマスターへのデルファイ調査（予備的）では、デイリースクラムが従来の15分の枠を超えて延長され、チームビルディング活動を含めることが多いと報告された[32]。

パンデミックから約 1 年後の質問紙（96 人）とインタビュー（7 人）では、スタンドアップの頻度は以前とほぼ同じだが、わずかに増える傾向があり、日中の自然な同期の不足を補うために 1 日の回数を増やしたと答えた人がいた[33]。

在宅勤務でスクラムを行った 12 人へのインタビューでは、多くの対象者が、対面のときと比べてデイリースクラムの時間が延長されたと述べた[34]。

ノルウェーの超大規模開発プログラムの事例研究では、プロジェクトで行われた決定の多くは、関係するステークホルダー間で非公式に議論されたあと、デイリースクラム、スクラム・オブ・スクラム、メタスクラムのいずれかの公式な場で正式に決定されていたことが分かった[35]。

デイリースクラムは、プロジェクトの進捗を追跡し問題へ迅速に対応するために毎日約15分間開催される短時間のミーティングである[36]。

デイリースクラムは、障害の特定と日々のコミットメントの見直しを通じて、非難のない相互支援や心理的安全性を促進する場として機能する[37]。

分類・所属

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

オントロジー上の位置

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

Process Constraints (プロセス制約)

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

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

  • E5 [警告] (DailyScrum): デイリースクラムに外部ステークホルダーが参加(participatesIn)しています。スクラムガイドでは、デイリースクラムはスクラムチームの開発者のための15分のイベントです。デイリースクラムに外部の参加者を加えるテーラリングが報告されています（Özkan & Özcan-Top, 2022）。

脚注

Section titled “脚注”

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

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

  3. Scrum: An Agile Software Development Process and Metrics — 「4.3.1 デイリースクラムとスプリントレトロスペクティブ デイリースクラムは、チーム内のコミュニケーションを改善し、障害（インペディメント）を特定して早期解決を図り、迅速な意思決定を促進してチームの知識レベルを向上させます。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

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

  5. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「- デイリースクラム（毎日のスタンドアップミーティング）や密接なコラボレーションを通じて、チームのコミュニケーションを強調します。」（原文: “Emphasize team communication with daily stand-up meetings and close collaboration.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  6. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  7. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

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

  9. Scrum Guide 2013 — 「デイリースクラムとは、開発チームが活動の速度を合わせ、次の 24 時間の計画を作る 15 分 間のタイムボックスのイベントである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  10. Scrum Guide 2020 — 「デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  11. Scrum@Scale Guide — 「スケールされたデイリースクラムとレトロスペクティブは、グループのスクラムマスター(スクラムオブスクラムマスター、SoSM と呼ばれる)がファシリテートする。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  12. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「- c) デイリースクラム: 次の24時間以内の作業を計画するためにスプリントの毎日開催される15分間のSTミーティングであり、前回のデイリースクラム以降に作成された作業を検証し、スプリントの次の作業を予測することで、チームのコラボレーションとパフォーマンスを最適化します。」（原文: “c) Daily Scrum is a ST 15-min meeting held every day of the sprint for planning the work within the next 24 h, which allows for optimizing team collaboration and performance as the work produced since the last daily scrum is scrutinized, and sprint’s next work is predicted;”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  13. Scrum Guide 2017 — 「デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  14. Scrum Guide Expansion Pack — 「デイリースクラムはイベントの一つである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

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

  16. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「このサイクルは、既存のスクラムイベントを通じて運用できます。リファインメントによって不確実性を特定し、エビデンスの必要性を準備できます。スプリントプランニングでは、選択されたストーリーが十分に理解され実現可能であることを検証できます。デイリースクラムでは、チーム全体の進捗とブロッカーを調整できます。スプリントレビューでは、提供された価値と残された前提条件を評価できます。そしてレトロスペクティブでは、コラボレーション、トレーサビリティ、プロトタイプ、フローのポリシーが学習を支援したかどうかを評価できます。」（原文: “This cycle can operate through existing Scrum events. Refinement can identify uncertainty and prepare evidence needs; Sprint Planning can verify that the selected story is sufficiently understood and feasible; the Daily Scrum can coordinate collective progress and blockers; the Sprint Review can evaluate delivered value and remaining assumptions; and the retrospective can assess whether the collaboration, traceability, prototype, and flow policies supported learning.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  17. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

  19. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2

  20. Dependencies of Agile Teams – An Analysis of the Scaled Agile Framework — 「チームは、典型的なスクラムのプラクティス（スプリント計画、デイリースクラム、デモ、レトロスペクティブ）を適用し、スクラムの役割（スクラムマスターとプロダクトオーナー）を使用します。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

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

  22. Responding to change over time: A longitudinal case study on changes in coordination mechanisms in large-scale agile（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

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

  24. Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  25. Nexus Guide — 「各スクラムチームのデイリースクラムは、 Nexus デイリースクラムを補完するものである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  26. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「デイリースクラムは、他のチームのメンバーが見学（オブザーブ）することによって、チーム間の調整のために使用することもできる。」（原文: “The Daily Scrum can also be used for coordination between teams by having people from other teams observe.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  27. Systematic Literature Review Report on the Challenges of Agile Scrum — 「デイリースクラムミーティング、デイリースクラムオブスクラムミーティング、スプリントレビューミーティング、スプリントプランニングミーティングがアジャイルスクラムのセレモニーを構成する。」（原文: “Daily Scrum Meeting, the Daily Scrum of Scrums Meetings, the Sprint Review Meetings and the Sprint Planning Meetings constitute Agile Scrum ceremonies.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

  29. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  30. Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study — 「デイリースクラムでは、スクラムマスターが会議中に共有された極めて重要な情報を要約し、全員がそれを理解したかを確認することになった。」（原文: “At the Daily Scrum, Scrum Master was to recapitulate crucial information that had been given during the meeting and to make sure that everyone had grasped it.”）（訳）（ライセンス: CC BY 4.0） ↩

  31. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  32. A Delphi Study on the Adaptation of SCRUM Practices to Remote Work — 「デイリースクラムも進化しており、従来の15分の枠を超えて延長され、絆やエンゲージメント、帰属意識を強化するチームビルディング活動を含めることが多く、対面での偶発的なやり取りの喪失を緩和するのに役立っている。」（訳）（ライセンス: CC BY 4.0） ↩

  33. Agile software development one year into the COVID-19 pandemic — 「回答者はスタンドアップの頻度は以前とほぼ同じであると報告したが、わずかに増加する傾向への変化が見られた。」（訳）（ライセンス: CC BY 4.0） ↩

  34. The impact of working from home on the success of Scrum projects: A multi-method study — 「多くのインタビュー対象者は、オンサイト版と比較してデイリースクラムの時間が延長されたと述べており、これは一般化可能な知見と見なすことができます。」（訳）（ライセンス: CC BY 4.0） ↩

  35. Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation — 「プロジェクトで行われた決定の多くは、関係するステークホルダー間で非公式に議論された後、デイリースクラム、スクラム・オブ・スクラム、またはメタスクラムといった公式な場のいずれかで正式に決定されていたことが分かった。」（原文: “We learned that many of the decisions made in the project were discussed between relevant stakeholders informally and then officially decided upon in one of the formal arenas, the daily Scrums, Scrum of Scrums, or the Metascrum.”）（訳）（ライセンス: CC BY 4.0） ↩

  36. Scrum: A Systematic Literature Review — 「デイリーミーティング（デイリースクラム）は約15分間行われ、プロジェクトの進捗を追跡するために開催される。」（原文: “Daily meetings last around 15 minutes, and are organized to track project progress.”）（訳）（ライセンス: CC BY 4.0） ↩

  37. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「各項目は、意図された行動の焦点に基づき、スクラムイベント（スプリントプランニング、デイリースクラム、スプリントレビュー、またはスプリントレトロスペクティブ）に明示的にマッピングされた。」（原文: “Each item was explicitly mapped to a Scrum event—Sprint Planning, Daily Scrum, Sprint Review, or Sprint Retrospective—based on its intended behavioral focus.”）（訳）（ライセンス: CC BY 4.0） ↩