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

スプリントレトロスペクティブ (Sprint Retrospective)

概要

Section titled “概要”

スプリントレトロスペクティブは、スプリントの締めくくりにスクラムチームが自身のプロセスや働き方を検査・適応し、品質や有効性を継続的に向上させるためのスクラムイベントである。スプリントレビュー後に実施され、人間関係、ツール、完成の定義、新手法の導入に伴う作業方法の変化などを多角的に省察する。心理的安全性を基盤とした対話を通じて持続的な課題に対処し、持続可能な開発ペースの維持やプロセス効率向上に向けた実用的な改善策を合意してチームの自律性を育む。大規模環境や組織展開においては単一チームの改善にとどまらず、チーム間や外部機能とのインターフェース課題を振り返り、調整メカニズムを再構成して組織的な変化への適応を促すボトムアップの原動力としても機能する。

詳細

Section titled “詳細”

  • 概念の定義と目的： スクラムチームが自身の品質、プロフェッショナリズム、有効性（エフェクティブネス）およびパフォーマンスを高めるため、プロセスや働き方を最適に調整・改善するスクラムイベントである[1][2][3][4][5][6][7][8]。チームメンバーがリーダーシップと意思決定権を共有し、プロセスとタスクのパフォーマンスを自律的かつ客観的に評価する場としても機能する[9]。プロダクトそのものの評価ではなく、作業プロセスの健全性や成果、課題に焦点を当てて自己検査する[10]。アジャイルプロセスを持続可能にし、チームの機敏性を高めるため、直近のスプリントでの取り組みを自ら検査し、次のスプリントに向けた具体的で効果的な改善計画を作成・合意することを目的とする[1][3][4][5][6][7][8][10]。スクラムマスターはイベントが確実に開催されタイムボックス内に収まるようファシリテートを行うとともに、スクラムプロセスの範囲内でポジティブで生産的な場となるよう促し、チームの改善を支援する[4][6][7]。当事者であるチームメンバー単独では単なる計画会議化してしまうリスクがあるため、客観的な調整を担うスクラムマスターによる中立的なファシリテーションが不可欠とされる[11]。また、チーム単独での解決が難しい課題については、必要に応じてサポーターの支援を受けながら組織的な障害除去を図る[8]。

  • 参加者と実施タイミング・タイムボックス： スプリントの締めくくり（最後）として、スプリントレビュー終了後かつ次のスプリントプランニングの前に実施され、このイベントをもって1つのスプリントが終了する[12][3][4][7][8]。外部のステークホルダーは含めず、プロダクトオーナー、開発者（旧開発チーム）、スクラムマスターで構成されるスクラムチーム全体のみで実施する[10][13][4][5][6][7]。1か月（4週間）のスプリントにおけるタイムボックス上限は、初期の規定では3時間[12][14]や4時間（または最大4時間）[3]とされていたが、その後のガイド規定等では最大3時間（または最大3時間程度）とされており[4][5][6][15][8][16][7]、より短いスプリントでは短縮される[7]。会議の肥大化を防ぎ開発者の集中と生産性を維持するために、例えば2週間の反復では最大90分のように適切なタイムボックスを設定して実施される[9]。

  • スプリントの検査・再評価と分析対象： 心理的安全性が確保された環境で実施され[8]、スプリント中に上手く進んだ点・困難だった点・改善すべき変更点などを扱う。対象は、スプリントサイクル全体における個人（人・人々）・人間関係（相互作用・協働関係）・プロフェッショナリズム・スクラムチームのダイナミクス・プロセス・開発方法・開発運用・ツール・スクラムチームの構成・ミーティング規約・コミュニケーション手法・インクリメント・アウトカム・完成（完了）の定義（Done）といった多角的視点にわたり、直近のスプリント活動やプロセスの健全性を自己検査・評価・再評価する[12][10][17][13][15][2][3][4][5][6][7][8]。プロダクト成果物そのものではなく作業プロセスにおける成果や課題、良かった点（効果的な技術やパターンなど）、直面した問題点を特定・再評価し、表面的な問題にとどまらず失敗した仮説の根本原因やシステム上の要因を特定して解決策を検討する[12][3][4][5][6][7][15][8][16][10][17][18]。業務上の障害の特定に加え、感情の共有、チームダイナミクスや対立の議論も行われる[9]。プロダクト品質および開発効率向上の観点から「完成の定義」の調整や強化・適性化・厳格化も計画する[3][4][6][7][15][8][17]。さらに、スプリント終了時に残った未完了タスクも重要な分析対象となり、プロセスの問題を明瞭にする[19]。大規模で分散した 1 つのアジャイル組織で、37 回のチームレベルのスプリントレトロスペクティブを約 3 年追った事例研究では、議論の大部分は、チームにとって身近で制御できる話題に向けられていた[20]。

  • チーム有効性と継続的改善を向上させる要素： チーム内の心理的安全性が確保され、メンバーが率直に意見を表明して気に入らない点や改善すべき問題をオープンに議論できる安全な環境を育むこと、および共同学習の機会が基盤として存在することが、質の高いレトロスペクティブを実現し、チームの有効性を向上させる上で重要である[18][8][11]。また、相互支援（ピアサポート）やコミュニケーションの透明性を高めることにも寄与する[9]。多様なフォーマットを活用することで実効性のある具体的な改善アクションを抽出したり[18]、ゲームベースの手法などを導入してエンゲージメントを高めつつ継続的なプロセス改善を促進するアプローチが有用とされる[19]。さらに、チームが自律的に改善策を実行するコントロール感を醸成することで、感情的な疲労の抑制やエンゲージメントの向上にも寄与する[9]。チームがどのような形でリーダーシップ役割を引き受けるかについて定期的に振り返り内省・議論する場を提供することで、チームの成熟と自己組織化を前進させる契機となる[11]。加えて、チームが直面する持続的な課題を解決するためのオープンな対話と学習の場としても機能する[21]。6 つのスクラムチームにレトロスペクティブゲームを導入した Action Research では、ゲームが構造の欠如・退屈さ・多すぎる不平不満・不均等な参加といった困難を軽減し、ミーティングをより生産的にしたと報告された[22]。

  • 改善計画の作成、フィードバックの反映と実行： 継続的改善を推進するための核心的なイベントであり、少なくとも1つの実用的な改善策を生み出すことが質の高いレトロスペクティブの条件とされる[21]。これらの改善項目はチームの有効性を高めるための最も影響の大きな改善として特定され[7][8]、優先順位が設定された上で早期かつ可能な限り迅速に実行される[8][15][17][16][11]。さらに、少なくとも1つの優先度の高い改善策を次のスプリントバックログに含めることが義務付けられた時期もあったが[6]、現在では実行可能性を高めるために必要に応じて次のスプリントバックログに追加されることもあるとする柔軟な記述へと改訂されている[7][15][12][14][3][4][5]。これらの改善点は次回のタスク優先順位付けやバックログ管理にも反映され、迅速に実行される[2][8][15][16][17]。

  • 新たなエンジニアリング手法の導入とプロセスの調整： アーキテクチャ不確実性管理手法の適用状況などを含め、スプリント終了時にプロセス全体や作業方法について振り返りを行い、改善点を議論する実践も存在する[23]。新たな活動の追加や作業方法の変化に伴う課題についてチーム内で共有しプロセスの調整を図ることで、持続可能な開発ペースの維持やプロセス効率の向上を目的としたチーム主導の適応活動を推進する[23]。

  • 分散・リモートワーク環境における評価と課題： 分散環境やリモートワーク環境下においてもチームワークの有効性向上やプロセスの最適化を支援し、チームの評価や検討として実施されるが[13][2]、対面環境と比較して心理的安全性の確保や、本質的な問題に対するメンバー間のオープンな議論、作業・議論の透明性を確保しにくい点が主な課題として挙げられる[13]。リモートに移った 1 社の Action Research の行動計画では、レトロスペクティブの最後に、完了したアクションポイントと新たに決めたものの両方を要約することが取り決められた[24]。多国籍電気通信企業 Ericsson の 2 ユニット（15 チーム、27 人へのインタビュー）の研究は、レトロスペクティブや技術的議論のように活発な議論やブレインストーミングを要するミーティングは対面での参加が有益で、大規模な情報共有ミーティングはリモートでも効果的に機能すると報告した[25]。

  • フロー指標とワークフローの検査・適応： 平均サイクルタイムや平均スループット、累積フロー図などのデータを活用してプロセスの課題を明確化し、仕掛品（WIP）制限やサービスレベル期待値（SLE）を含む「ワークフローの定義」自体を検査・適応（変更）する手法が用いられる[26]。このような定義変更を定期的なレトロスペクティブのリズムで行うことで、プロセスの複雑性を軽減し、透明性と集中を向上させることができる[26]。

  • Nexusにおける全体的な改善： 複数チームで連携する大規模環境では、各チームの振り返りを補完・強化する「Nexusスプリントレトロスペクティブ」が実施される[27]。個人、チーム、相互作用、プロセス、ツール、完成の定義を対象にNexus全体での振り返りを行い、各チームのレトロスペクティブと相乗効果を持たせながら、ボトムアップで収集された情報から個別チーム内にとどまらない問題の特定と解決を図る[27]。取り組み全体を検査して具体的な改善策を決定し、このイベントをもって1つのスプリントが完了する[27]。

  • Scrum@Scaleにおける組織的展開と障害解決： スケールされた環境では各チームのスクラムマスターが集まり、スクラムオブスクラムマスターのファシリテーションのもと、複数チームに共通するプロセスの改善点や実施した実験結果・成果について議論する[28]。成功した効果的な改善策を組織全体へ共有・横展開するとともに、障害物の根本原因を突き止め、組織レベルの改善活動へと繋げる[28]。

  • スケーリングフレームワークにおける意思決定と改善の構造： 大規模アジャイルフレームワークにおけるレトロスペクティブでの意思決定構造を比較すると、改善項目やその形式の決定者、および決定プロセスに明確な差異が存在する[29]。標準的なスクラムではチーム全体で改善項目を決定して次のスプリントバックログに組み込み、SAFeでもチームが合意の上で改善方法を決定する[29]。また、SAFeにおけるレトロスペクティブの形式は通常チーム自身が決定するが、独裁的な決定権を持つファシリテーターをローテーションさせる運用も認められている[29]。LeSSにおいては、チーム個別の反省会に加えて開発チーム全員が集まりスプリント中の連携方法を決定する「全体的反省会（Overall Retrospective）」が設けられ、全員の合意に基づいて改善が決められる[29]。さらにLeSSでは、コミュニティ（CoP類似）が開発チーム、顧客、ステークホルダー、プロダクトオーナーと協力して改善策を決定するアプローチも採用される[29]。対照的に、Scrum@Scaleのスケーリングされたレトロスペクティブでは、改善項目やその方法の決定権は各チームのスクラムマスター（スプリントマスター）に委ねられており、スクラムマスター間の合意によって決定される[29]。このようにスケーリング環境においては、複数チームの課題や組織的障害に対処するための拡張されたレトロスペクティブ（Scaled Retrospectives）が導入される場合がある[21]。

  • ビジネスチームおよびSAFe環境における適用とインターフェース改善： ソフトウェア開発チームにとどまらず、ビジネスチームが独自のアジャイルな働き方を構築・進化させるための継続的改善プラクティスとしても適用される[30]。また、アジャイルリリーストレイン（ART）全体の共同同期イベントとして実施され、チーム間や外部機能・他部門とのインターフェースにおける課題や依存関係を振り返り、協調体制を改善する機会としても機能する[30]。

  • 現場におけるテイラリングの実態とアンチパターン： アジャイルやスクラムに対する理解不足などを理由に、イベントの省略（一切開催しない）や、議論の時間を15分程度と極端に短く設定するようなテイラリングの実施事例が報告されている[31]。このような非開催や極端な短縮といったスクラムガイドの意図に反するテイラリングは、実行可能な改善項目を特定できず継続的改善の機会を喪失させるため、アドホックな開発アプローチや元のプロセスに逆戻りしてしまう要因となる[31]。ソフトウェア開発組織の調査（回答者42人）では、「レトロスペクティブがない」反パターンの表IX重み付けスコアが27.38%（満点168に対する割合で、組織の割合ではない）であった[32]。さらに、「スプリントレビューとレトロスペクティブという2つの会議を1つにまとめる」反パターンの重み付けスコアは26.79%（満点168に対する割合）であった[32]。目的の異なるレビューと振り返りを混同・統合することは、プロセスの内省やチーム改善のための独立した機会を奪うリスクをもたらす[32]。

  • 大規模環境・導入現場における課題とアジャイルコーチング： 大規模プロジェクト等の現場では、プロセス改善の機会として期待される一方で運用上の課題も報告されている[33]。他の多くの儀式・会議体とともに頻繁に実施されることで会議過多による疲弊を招き、開発時間を削る過剰な会議の一つとして不満の対象となる場合がある[33]。また、メカニスティックな規律と有機的なリーダーシップのバランスが取れていない場合、振り返りを行っても十分な改善やサポートにつながらず、継続的改善が不足して形骸化することがある[33]。レトロスペクティブを有意義に機能させ、継続的な改善と開発文化の定着を図るためには、適切な導入ガイダンスとアジャイルコーチによる支援が不可欠とされる[33]。

  • 大規模環境における組織的統制とチーム自律性の調和： 大規模アジャイルソフトウェア開発における組織的統制とチームの自律性のバランスを扱った事例研究では、レトロスペクティブが自律的に作業プロセスを監視・管理し最適化するための主要な手段として位置づけられる[34]。チームはレトロスペクティブを通じて、スクラムやカンバンのプラクティスを自分たちの実情に合わせて柔軟に変更・調整する内部プロセスの適応を図る[34]。また、二重ループ学習を実践し、チームの生産性と作業環境の向上に向けた具体的な改善策を自発的に合意して継続的改善を推進する[34]。一方で、組織横断のルールとの境界が存在し、チーム内部の手順はレトロスペクティブで自由に変更可能であるものの、プロジェクト全体の共通ツールや品質チェックリストの変更にはコミュニティ全体での議論が必要となる[34]。さらに、チームが直面した課題を吸い上げ、上位のガバナンスやコミュニティに対して組織的な改善提案を行うボトムアップ改善の起点としても機能する[34]。

  • 大規模環境における調整メカニズムの再構成とチーム間展開： 大規模アジャイル環境において、レトロスペクティブは単一チーム内の改善にとどまらず、プロダクトオーナー同士やチームリーダー間など、役割ごとの「チーム間レトロスペクティブ」としても運用される[35]。これにより、現場で生じたコミュニケーション上の摩擦や作業遅延を特定し、新しいプラクティスやツール運用の改善策を導出するボトムアップ改善の推進力となる[35]。さらに、プロダクトオーナーの優先順位決定会議の簡素化・廃止やチーム間スタンドアップ会議のアジェンダ見直しなど、効果を失った調整メカニズムの修正や廃止を決定する場としても機能する[35]。また、外部・内部の変化イベントが発生した際に過去の教訓を振り返り（オンボーディング後の振り返りワークショップなど）、将来のプロセスを柔軟に適応させる基盤を提供することで、組織全体の変化適応力を向上させる[35]。

  • デザインベース研究（DBR）における省察ステージとしての拡張： DBRにおいては単なるプロセスの改善にとどまらず、研究課題やデータ収集戦略を同時に見直し洗練させる「省察ステージ」として拡張されて機能する[36]。「どのようなデザイン原則が浮かび上がったか」や「どのアクセシビリティの前提が覆されたか」といった研究上の問いを振り返りの議題に含めることで、アジャイルのデリバリー速度を維持しつつ、デザイン研究としての科学的厳密性を担保するための調整メカニズムの役割を果たす[36]。

スプリントレトロスペクティブは各スプリントの完了後に開催され、チームメンバーはすべてが順調であるか、何らかの改善が必要であるかを判断し、将来のスプリントに向けて適切なアクションを取る[37]。

リモートワークへのスクラム実践の適応を扱ったデルファイ調査（予備的）では、スプリントレトロスペクティブにエンゲージメントと内省を促す遊び心のある要素が取り入れられたが、その効果については専門家の意見が分かれた[38]。

チェコの大企業 4 社の 8 人へのインタビューでは、チームが必要性を感じていない場合や十分なフィードバックが得られない場合に、レトロスペクティブが省略されたり、デイリースタンドアップなど他のイベントの中で扱われたりすることが多かった[39]。

パンデミックから約 1 年後の調査では、多くの実務者がレトロスペクティブはより困難になったと答え、インタビューでは、ボディランゲージや合図の欠如と発言の重なりが理由に挙がった[40]。

在宅勤務でスクラムを行った 12 人へのインタビューでは、オンラインのスプリントレトロスペクティブは、多くの対象者にとって対面ほど快適ではなく、人々が声を上げて自己表現するのを促す場が同じようには得られないと語られた[41]。

スプリントレトロスペクティブは、チームが自らのプロセスや作業方法を振り返り、次期スプリントに向けた改善策を導出するためのイベントである[42]。

STEM-EFにおいてスプリントレトロスペクティブは、パフォーマンスの振り返り、教訓の議論、次期スプリントに向けた変更計画という3つの中核活動を通じて感情的要因が最も顕著に現れる場として重視される[43]。

分類・所属

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

オントロジー上の位置

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

Process Constraints (プロセス制約)

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

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

  • E1 [警告] (SprintRetrospective): スプリントレトロスペクティブを含むスプリントの作業（スプリントバックログの計画タスク、またはこのスプリントで実行されたタスク）に、レトロ由来のタスク（srom:fromRetrospective が true）が1件もありません。前回のレトロで決めた改善が、このスプリントの作業になっていない可能性があります（Verwijs & Russo, 2022）。

脚注

Section titled “脚注”

  1. Principles behind the Agile Manifesto（ライセンス: 著作権あり・告知を含む全文に限り複製可） ↩ ↩2

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

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

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

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

  6. Scrum Guide 2017 — 「スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会 である。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  7. Scrum Guide 2020 — 「スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  8. Scrum Guide Expansion Pack — 「スプリントレトロスペクティブはイベントの一つである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

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

  10. Scrum: An Agile Software Development Process and Metrics — 「スプリントレトロスペクティブは、スクラムチームがスクラムプロセス内で自己検査を行い、次のスプリントの成果をより効果的にするための改善の機会です。」（原文: “The sprint retrospective is an opportunity for the Scrum Team to introspect improve within the Scrum process so as to make the next sprint outcome more effective.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  11. Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature — 「あるチームは、 retrospective をチームメンバーが主導する形で実施しようと試みましたが、結果として計画会議になったと報告しています。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

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

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

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

  15. Scrum Guide (LeSS Version) — 「スプリントレトロスペクティブは、スプリントの締めくくりとなるイベントである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  16. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「- e) スプリントレトロスペクティブ: スプリントレビューの後、次のスプリントプランニングの前に開催されるミーティングであり、DTが自己検査を行い、次のスプリント中に適用する改善計画を作成するもので、1ヶ月のスプリントで最大3時間、より短いスプリントではそれ以下となります。」（原文: “e) Sprint Retrospective is a meeting held after the Sprint Review and prior to the next Sprint Planning, which can last a maximum of 3 h for a 1-month sprint or less for shorter sprints, where the DT inspect itself and create an improvement plan to be applied during the next sprint.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  17. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「スプリントレビューの後、チームの作業を改善するためにプロセスをふりかえり、調整するためのスプリントレトロスペクティブミーティングが開催されます。」（原文: “After the Sprint review, the Sprint retrospective meeting is held to review and adjust the process to improve the team’s work.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

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

  19. Agile Software Development with Secure and Scrum-Centric Approach — 「- Przybyłek, A., Albecka, M., Springer, O., & Kowalski, W. (2022). ゲームベースのスプリントレトロスペクティブ：マルチアクションリサーチ。」（訳）（ライセンス: CC BY-SA 4.0） ↩ ↩2

  20. Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives — 「議論の大部分は、チームにとって身近で制御可能なトピックに関連していた。」（原文: “Most discussions were related to topics close to and controllable by the team.”）（訳）（ライセンス: CC BY 4.0） ↩

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

  22. Game-based Sprint retrospectives: multiple action research — 「ふりかえりゲームは構造の欠如、退屈さ、多すぎる不平不満、不均等な参加といった、スプリントレトロスペクティブに付随する多くの「偶発的な困難」をチームが軽減するのに役立った。また、ミーティングをより生産的なものにした。本研究の副次的効果として、ふりかえりに関する主な問題はミーティングの進行方法そのものではなく、経営陣が組織レベルの是正措置に協力的でない中で、チームのコントロールが及ばない繰り返される問題に対する非生産的な議論にあることが判明した。」（訳）（ライセンス: CC BY 4.0） ↩

  23. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「スプリントレビューのセレモニーでは、チームは納品されたパッケージの品質について議論し、それに続いてスプリントレトロスペクティブで、ArchHypoへの適応を含め、プロセスがどのように実行されたかを議論した。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  24. Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study — 「スプリントレトロスペクティブでは、完了したアクションポイントと新しく設定されたアクションポイントの双方が最後に要約されることになった。」（原文: “During the Sprint Retrospective, both the completed action points and newly established ones were to be recapped at the end.”）（訳）（ライセンス: CC BY 4.0） ↩

  25. Hybrid Work in Agile Software Development: Recurring Meetings — 「レトロスペクティブ（ふりかえり）や技術的議論など、活発な議論やブレインストーミングを要するミーティングは対面での参加が有益である一方、大規模な情報共有ミーティングはリモートでも効果的に機能する。」（訳）（ライセンス: CC BY 4.0） ↩

  26. Kanban Guide for Scrum Teams 2021 — 「フローベースのスプリントレトロスペクティブでは、流れの指標や分析の検査を追加す る。」（ライセンス: CC BY-SA 4.0） ↩ ↩2

  27. Nexus Guide — 「Nexus スプリントレトロスペクティブの目的は、 Nexus 全体の品質と有効性を向上させる方法を 計画することである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

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

  29. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

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

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

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

  33. Systematic Literature Review Report on the Challenges of Agile Scrum — 「過剰で長すぎるスクラムイベント（ミーティング）。 アジャイルフレームワークは、多くのセレモニー／イベント（デイリースタンドアップミーティング、プロダクトバックログリファインメント（グルーミング）ミーティング、スプリントレトロスペクティブ、スプリントレビュー／デモ、リリースイテレーションプランニングセッション、スクラムオブスクラム（SoS）、実践コミュニティ（CoP）など）で構成されている。」（原文: “Too many and Long Scrum Meetings. Agile framework consists of many ceremonies (daily standup meetings, product backlog grooming meetings, sprint retrospective, sprint review/demo, Release Iteration Planning sessions, Scrum of Scrum (SoS), Community of Practice (CoP), etc.).”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

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

  35. 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

  36. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「スプリントレトロスペクティブ（振り返り）は、スクラムのプロセスへの焦点を超えて拡張され、DBRの省察ステージにも対処するように拡張され、チームに研究の問いとデータ収集戦略の両方を洗練させるよう促しました。」（原文: “Sprint Retrospectives were expanded beyond Scrum’s process focus to also address DBR’s reflective stage, prompting the team to refine both research questions and data collection strategies.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  37. 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） ↩

  38. A Delphi Study on the Adaptation of SCRUM Practices to Remote Work — 「最後に、スプリントレトロスペクティブにはエンゲージメントと内省を促すために遊び心のある要素が取り入れられたが、その効果については専門家の意見が分かれた。」（訳）（ライセンス: CC BY 4.0） ↩

  39. Real-Life Water-Scrum-Fall: Insights from Large Companies in Czech Republic — 「レトロスペクティブについては、チームが実施の必要性を感じていない場合や、十分なフィードバックが得られない場合、省略されたり、デイリースタンドアップなど他のイベントの中で扱われたりすることがよくあります。」（訳）（ライセンス: CC BY 4.0） ↩

  40. Agile software development one year into the COVID-19 pandemic — 「数名のインタビュー対象者は、ボディランゲージや合図の欠如、レトロスペクティブ中に互いの発言が重なったり心を開かなかったりすることが、パンデミック前よりもレトロスペクティブが困難だと感じられる要因になっていると言及した。」（訳）（ライセンス: CC BY 4.0） ↩

  41. The impact of working from home on the success of Scrum projects: A multi-method study — 「特に、スプリントレトロスペクティブのオンライン体験は、多くの対象者にとってオンサイト版ほど快適なものではありませんでした。在宅勤務ができるという環境は、スプリントレトロスペクティブの一環として人々が声を上げ、自己表現することを促すような場を同じようには提供してくれません。」（訳）（ライセンス: CC BY 4.0） ↩

  42. Scrum: A Systematic Literature Review — 「最後にスプリントレトロスペクティブのステップがあり、これはチームを含めて次のスプリントの前に行われ、次のステージに向けた改善とより良い成果をもたらすことを目指す [39, 40]。」（原文: “Finally, there is the sprint retrospective step, which is carried out before the next sprint that includes the team, and seeks to bring about improvements and better results for the next stage [39, 40].”）（訳）（ライセンス: CC BY 4.0） ↩

  43. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「スプリントレトロスペクティブにおいて、スクラムマスターは直近のスプリントでチームメンバーがどの程度安全だと感じていたか、あるいは感情的なつながりを感じていたかを把握するために、STEM-EF調査を実施することがある。」（原文: “A practical example illustrates this use: during a Sprint Retrospective, a Scrum Master may administer the STEM-EF survey to capture how safe or emotionally connected team members felt in recent sprints.”）（訳）（ライセンス: CC BY 4.0） ↩