Wiki
スクラムに関する知識を自動で収集・整理・検証するためのLLM向けWiki
目的から選ぶ
Section titled “目的から選ぶ”| 目的 | 内容 | リンク |
|---|---|---|
| 📖 Wikiで読む | 用語・概念の解説をテキストで読んで理解する | スクラムから読み始める → |
| ❓ クエリで解決する | 現場の悩みや疑問に、文献の事例や公式根拠の検証で答えるページを読む | クエリと回答一覧 → |
実践者の悩み (Practitioner Questions)
Section titled “実践者の悩み (Practitioner Questions)”現場の実践者が抱えがちな悩みに、文献にある打ち手と事例で答えるページです。公式ルールの検証ではなく、文献の報告をまとめたものです。
- いまのやり方がスクラムに合わないと感じたとき、他の進め方に替えるかどうかを、どう考えるか？
- ふりかえりが浅くなったり、マンネリになったりして、改善につながる議論が出てこない。スクラムマスターはどうふりかえりの質を上げるのが良いか？
- スクラムを新しく始めるとき、最初に何をするのが良いか？（メンバーとステークホルダーへの準備・教育を含む）
- スクラムマスターは観察をするとありますが、具体的に何をすれば良いですか？
- スクラム未経験の新人やメンバーに、スクラムをどう教えるか？
- ステークホルダーと、どう関係をつくり、話すのが良いか？ 価値観の合わない相手とは、どう話すか？
- スプリントレビューが、デモを見せて終わりになり、実りあるフィードバックの場にならない。どうすれば実りあるものにできるか？
- チームがスクラムやアジャイルをできているかを、スクラムマスターはどんな観点やデータで見極めるのが良いか？
- チームのリードタイムなどの改善が停滞している。どんな打ち手があるか？
- チームの中に、他のメンバーとぶつかる言動を繰り返す人がいる。スクラムマスターはどう関わるのが良いか？
- チームの課題やボトルネックを発見するために、どのような指標・データを取って活用すべきか？
- トップダウンではなく、ボトムアップで始まったチームから、スクラムやアジャイルを組織に広げるにはどうするのが良いか？
- プランニングとゴール設定で、チームの協業をどう引き出すか？
- プロダクトオーナーの視座が低いと感じる。プロダクトオーナーをどう育成するのが良いか？
- 会議やイベントで発言量にばらつきがあり、一部の人しか話さない。メンバーの本音を引き出すには、どうすればよいか？
- 出社とリモートが混在するチームで、スクラムのイベントやチームづくりをどう運営するか？
- 固定期間のスプリントを崩さずに、チームの流速や開発量（スループット）を高めるにはどうすればよいか？
- 属人化をどう解消し、学びをチームや組織の共有知にするか？
- 生成 AI を使った開発で、チームの役割・進め方・ふりかえりはどう変わるか？ スクラムマスターは何を支援するか？
- 発注側と受注側が混在するスクラムチームで、違和感をどう乗り越えるか？
- 納期が固定で、遅れると残業になる。形だけのスクラムから抜けるには、どうすればよいか？
- 経営陣やマネージャーから、スクラムの効果を数字で示すよう求められた。どう説明すればよいか？
- 複数のプロジェクトから別々の業務を依頼される横断チームで、どのようにフローを維持・管理すればよいか？
公式仕様・オントロジーの検証 (Competency Questions)
Section titled “公式仕様・オントロジーの検証 (Competency Questions)”スクラムガイドなどの公式テキストと、オントロジー（SRO・KGO）の形式検証に基づき、現場で生じやすい疑問・誤解に答える検証リファレンスです。
Scrum Core
Section titled “Scrum Core”- インクリメントは何によって構成される？
- エピック（分解前の大きなユーザーストーリー）を、そのままスプリントバックログに入れてよいか？
- スクラムマスターが不在だったり、プロダクトオーナーと兼任だったりすると何がまずい？
- スクラムマスターやプロジェクトマネージャーが開発者にタスクを割り当ててもよいか？
- スプリントで承認された成果物が出ないと何が問題？
- スプリントに必要なイベント（スプリントプランニング／デイリースクラム／スプリントレビュー／スプリントレトロスペクティブ）が1つでも欠けていた場合、何が問題とされるか？
- スプリントに複数のスプリントバックログがあってはいけないのはなぜ？
- スプリントの長さ（タイムボックス）は状況に応じてスプリントごとに変えてよいか？
- スプリントゴールはスプリント期間中に変更してもよいか？
- スプリントバックログにタスクが1つもない状態は何がまずいの？
- スプリントプランニングが必ず1回なのはなぜ？
- スプリントレビューにステークホルダーが誰も来ないと何がまずい？
- タスクに見積もりがないと何が問題？
- タスクは必ずユーザーストーリーに紐づいていないといけないのはなぜ？
- デイリースクラムはスクラムマスターやPOへの進捗報告ミーティングか？
- プロダクトオーナーがバックログを管理しないと何が起きる？
- ベロシティをチーム間比較に使ってはいけないのはなぜ？
- マネジメントはスクラムチームに何をすべき？何をすべきでない？
- ユーザーストーリーに受け入れ条件がないと何がまずいの？
- レトロスペクティブをやったのに改善タスクが1つもないのは問題？
- 受け入れ条件や成果物を「機能要件か非機能要件か」「承認されたか、されていないか」のどちらかに必ず分類するのはなぜ？
- 完成の定義（DoD）を満たさなかった成果物を生んだタスクは、どう扱われるべきか（手戻りの考え方）？
- 心理的安全性ってスクラムで具体的に何を指す？
- 成果物やタスクの実行が、計画やユーザーストーリーと繋がっていないと何が問題？
- 成果物を「承認された」とみなす条件は？
Kanban & Flow
Section titled “Kanban & Flow”- 1つのユーザーストーリーが、ToDo/進行中/完了のうち複数の状態に同時になっているとなぜダメ？
- 1つの作業項目が同時に複数の状態（ToDo/進行中/完了）になっているのはなぜダメ？
- GitHub/Jiraでは完了扱いなのに、ボード上ではまだ進行中のユーザーストーリーが残っていると何が問題？
- WIP制限を守るべき対象に、スクラムのユーザーストーリーも含まれるのはなぜ？
- WIP制限を超えて作業項目を積んでしまうと何が問題？
- どの状態にも属さない「浮遊した」作業項目があると何が問題？
- スクラムのユーザーストーリーやバックログアイテムを、カンバンボードの1枚のカードとして扱ってよいのはなぜ？
- スクラムチームの「ワークフローの定義」に抜けている要素があると何が問題？
- スクラムチームは「ワークフローの定義」を持つべき、と言われるのはどういうこと？
- タスク（実際の作業）は、カンバンボードのカードとして数えないのはなぜ？
- ワークフローの定義に必要な要素（作業項目の定義・状態・WIP制御・ポリシー）が欠けていると何が問題？
- ワークフローの定義の範囲が、1つのスプリントを超えてよいのはなぜ？
- 前工程からの引き取りを待たずに割り込みで作業を投入すると何が問題？
- 外部トラッカーでは完了済みなのに、ボード上は進行中のままになっている（ゾンビWIP）と何が問題？
- 急な割り込みでユーザーストーリーがスプリントバックログに追加されると何が問題？
- 状態（ToDo/進行中/完了）を持たないユーザーストーリーやエピックがあると、なぜ問題として検出されるの？
グラフで探る
Section titled “グラフで探る”用語 (Entities)
Section titled “用語 (Entities)”Scrum Core
Section titled “Scrum Core”- スクラム (Scrum)
- スクラムの価値基準 (Scrum Values)
- スクラムの理論 (Scrum Theory)
- スクラムイベント (Scrum Events)
- ステークホルダー (Stakeholders)
- スプリントゴール (Sprint Goal)
- タイムボックス (Timebox)
- プロダクトゴール (Product Goal)
- プロダクトバックログアイテム (Product Backlog Item)
- リファインメント (Refinement)
- 作成物 (Artifacts)
- 完成の定義 (Definition of Done)
- 尊敬 (Respect)
- 検査 (Inspection)
- 機能横断型 (Cross-functional)
- 確約 (Commitment)
- 経験主義 (Empiricism)
- 経験的プロセス制御 (Empirical Process Control)
- 自己管理 (Self-Management)
- 自己管理スクラムチーム (Self-managing Scrum Team)
- 自己組織化 (Self-Organization)
- 見通し・予測・追跡 (Forecast, Projection, Tracking)
- 透明性 (Transparency)
- 適応 (Adaptation)
- 開発チーム (Development Team)
- 障害物 (Impediment)
Kanban & Flow
Section titled “Kanban & Flow”- カンバン (Kanban)
- カンバン・メソッド (Kanban Method)
- サイクルタイム (Cycle Time)
- サービスレベル期待値 (Service Level Expectation)
- スクラムバン (Scrumban)
- スループット (Throughput)
- トヨタ生産方式、TPS (Toyota Production System)
- フロー、流れ (Flow)
- フロー指標 (flow metrics)
- プルシステム (pull system)
- リトルの法則 (Little’s Law)
- ワークフロー (Workflow)
- 作業項目の年齢 (Work Item Age)
- 失敗需要 (Failure Demand)
- 現地現物 (Genchi Genbutsu)
- 進行中の作業 (WIP)
Scaling
Section titled “Scaling”- Large Scale Scrum (LeSS)
- Nexus (Nexus)
- Nexus スプリントバックログ (Nexus Sprint Backlog)
- Nexus スプリントプランニング (Nexus Sprint Planning)
- Nexus スプリントレトロスペクティブ (Nexus Sprint Retrospective)
- Nexus スプリントレビュー (Nexus Sprint Review)
- Nexus デイリースクラム (Nexus Daily Scrum)
- Nexus 統合チーム (Nexus Integration Team)
- Scaled Agile Framework (SAFe)
- Scrum at Scale (S@S)
- アジャイルリリーストレイン (Agile Release Train)
- エグゼクティブアクションチーム (Executive Action Team)
- エグゼクティブメタスクラム (Executive MetaScrum)
- クロスチームリファインメント (Cross-Team Refinement)
- スクラムオブスクラム (Scrum of Scrums)
- スクラムオブスクラムマスター (Scrum of Scrums Master)
- チーフプロダクトオーナー (Chief Product Owner)
- プロダクトビジョン (Product Vision)
Value & Metrics
Section titled “Value & Metrics”- アウトカム (Outcomes)
- イノベーションの能力 (Ability to Innovate)
- エビデンスベースドマネジメント (Evidence-Based Management)
- 中間ゴール (Intermediate Goal)
- 即時戦術ゴール (Immediate Tactical Goal)
- 市場に出すまでの時間、T2M (Time to Market)
- 戦略的ゴール (Strategic Goal)
- 未実現の価値 (Unrealized Value)
- 現在の価値 (Current Value)
- 重要価値領域 (Key Value Areas)
Related Fields
Section titled “Related Fields”- 4つの主要な指標 (Four Key Metrics)
- 9因子理論 (9-Factor Theory)
- ADOCモデル (Automated DevSecOps Compliance Model)
- ArchHypo (ArchHypo)
- BizDev (BizDev)
- CyberDevOps
- DevOps (DevOps)
- DevSecOps (Development Security Operations)
- Disciplined Agile Delivery (DAD)
- FOBICSフレームワーク (Framework for Observing Business Index Concerning Security)
- GRPIモデル (GRPI Model)
- MoSCoW法 (MoSCoW Method)
- OODA ループ (The OODA Loop)
- SECIモデル (SECI Model)
- STEM-EF (Scrum Teamwork Effectiveness Model – Emotional Factors)
- VIRUPCUS (VIRUPCUS)
- WAxフレームワーク (Work-as-x Framework)
- Wiegersによる優先順位付け (Wiegers Prioritization)
- eduScrum (eduScrum)
- 「新たなる新製品開発の方法」 (The New New Product Development Game)
- うめきゾーン (Groan Zone)
- アウトカム完成の定義 (Definition of Outcome Done)
- アウトプット完成の定義 (Definition of Output Done)
- アクセシビリティに焦点を当てたユーザーストーリー (Accessibility-Focused User Stories)
- アクティビティ (Activities)
- アジャイル (Agile)
- アジャイルDAD (Agile DAD)
- アジャイルのロジスティクス (Agile Logistics)
- アジャイルエンタープライズ (Agile Enterprise)
- アジャイルエンタープライズアーキテクチャ (Agile Enterprise Architecture)
- アジャイルコーチング (Agile Coaching)
- アジャイルコーチング・グロースホイール (Agile Coaching Growth Wheel)
- アジャイルスクラム (Agile Scrum)
- アジャイルソフトウェア開発 (Agile Software Development)
- アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development)
- アジャイルチームワーク有効性モデル (Agile Teamwork Effectiveness Model)
- アジャイルハイブリッドアプローチ (Agile Hybrid Approach)
- アジャイルマインドセット (Agile Mindset)
- アジャイルマニフェスト
- アジャイル性とプロジェクト成功 (Agility and Project Success)
- アジャイル要求工学 (Agile Requirements Engineering)
- アジャイル要素 (Agile Elements)
- アジャイル開発 (Agile Development)
- アジャイル開発におけるセキュリティ実践 (Security Practices in Agile Development)
- イネーブリング・リーダーシップ (Enabling Leadership)
- インフラストラクチャ・アズ・コード (Infrastructure as Code)
- ウォータースクラムフォール (Water-Scrum-Fall)
- ウォーターフォールモデル
- エセアジャイル (Faux-Agile)
- エビデンス (Evidence)
- エンパワリングリーダーシップ (Empowering Leadership)
- オンボーディング (Onboarding)
- オーケストレーションされた休止 (Orchestrated Pauses)
- カノモデル (Kano Model)
- カンバン実践 (Kanban Practice)
- カンバン成熟度モデル (Kanban Maturity Model)
- ガバナンス (Governance)
- キュー理論 (Queueing Theory)
- クネビン (Cynefin ®)
- クリティカルチェーン・プロジェクトマネジメント (Critical Chain Project Management)
- クワイエットタイム (Quiet Time)
- ケイデンス (Cadence)
- ゲーム理論 (Game Theory)
- コスト・バリューランキング (Cost-Value Ranking)
- コミュニケーション (Communication)
- コミュニケーションの効率性 (Communication Efficiency)
- コミュニケーションの有効性 (Communication Effectiveness)
- コーディネーション戦略 (Coordination Strategy)
- サラスのビッグファイブモデル (Salas Big Five Model)
- サーバントリーダーシップ (Servant Leadership)
- シェアドリーダーシップ (Shared Leadership)
- システムチーム (System Team)
- システム思考 (Systems Thinking)
- シフトレフトセキュリティ (Shift-Left Security)
- スキル主導型モデル (Skill-Driven Model)
- スクラムの利用 (Scrum Usage)
- スクラムアジャイル分散ソフトウェア開発 (Scrum Agile Distributed Software Development)
- スクラムチーム有効性モデル (Scrum Team Effectiveness Model)
- スケーリング (Scaling Scrum)
- スケーリングフレームワーク (Scaling Frameworks)
- スプリントバーンダウンチャート (Sprint Burndown Chart)
- セキュアコーディング (Secure Coding)
- セキュアソフトウェアのアジャイルエンジニアリング (Agile Engineering of Secure Software)
- セキュアソフトウェア開発フレームワーク (Secure Software Development Framework)
- セキュアソフトウェア開発メソドロジー (Secure Software Development Methodology)
- セキュリティチーム (Security Team)
- セキュリティトレーニング (Security Training)
- セキュリティポリシー (Security Policy)
- セキュリティ・アズ・コード (Security as Code)
- セキュリティ専門家 (Security Expert)
- セキュリティ役割 (Security Role)
- セキュリティ成果物 (Security Deliverable)
- セキュリティ活動 (Security Activity)
- セキュリティ要件工学 (Security Requirements Engineering)
- セキュリティ要素 (Security Element)
- セキュリティ開発者 (Security Developer)
- セーフティのためのスクラム (Scrum for Safety)
- ソフトウェアセキュリティ要件 (Software Security Requirements)
- ソフトウェアプロダクトラインエンジニアリング (Software Product Line Engineering)
- ソフトウェア開発ライフサイクル (Software Development Lifecycle)
- チェンジエージェント (Change Agent)
- チームのパフォーマンス (Team Performance)
- チームの反省性 (Team Reflexivity)
- チームの成熟度 (Team Maturity)
- チームの自律性 (Team Autonomy)
- チームサイエンス (Team Science)
- チームダイナミクス (Team Dynamics)
- チームビルディングセレモニー (Team-Building Ceremony)
- チームベロシティ (Team Velocity)
- チームワークトレーニング (Teamwork Training)
- チーム間コーディネーション (Inter-team Coordination)
- テスト駆動開発 (Test-Driven Development)
- デジタルナレッジストレージ (Digital Knowledge Storage)
- デジタルナレッジマネジメント (Digital Knowledge Management)
- デジタルナレッジ共有 (Digital Knowledge Sharing)
- デジタル技術を通じたナレッジ活用 (Knowledge Utilization Through Digital Technologies)
- データ駆動型の意思決定 (Data-Driven Decision Making)
- トランザクティブ・メモリー・システム (Transactive Memory Systems)
- ナッジ理論 (Nudge Theory)
- ナレッジマネジメント (Knowledge Management)
- ハイブリッドなアジャイルスケーリング (Hybrid Agile Scaling)
- ハイブリッドワーク (Hybrid Work)
- ビジネス・アジリティ (Business Agility)
- ピアフィードバック (Peer Feedback)
- ファンチャート (Fan Chart)
- フィーチャーコンセプトスタディ (Feature Concept Study)
- フィードバック (Feedback)
- フルキット (Full-Kit)
- フローの三重らせん (The Triple Helix of Flow)
- フローシステム (The Flow System)
- ブラインドスプリント (Blind Sprints)
- ブースト理論 (Boost Theory)
- プラクティス (Practice)
- プラットフォームチーム (Platform Team)
- プランニングゲーム (Planning Game)
- プレプランニング (Pre-Planning)
- プロジェクト化 (Projectification)
- プロジェクト成功要因 (Project Success Factors)
- プロセスマイニング (Process Mining)
- プロダクト思考 (Product Thinking)
- ペアプログラミング (Pair Programming)
- ペネトレーションテスト (Penetration Testing)
- マルチチームシステム、MTS (Multiteam Systems)
- ムダ (Waste)
- モチベーション・クラウディング (Motivation Crowding)
- モデルベースソフトウェア工学 (Model-Based Software Engineering)
- モブプログラミング (Mob Programming)
- ユーザーカード (User Card)
- ユーザーストーリーに基づく要件品質評価手法 (Requirement Quality Assessment Method Based on User Stories)
- ユーザーストーリーモデル (User Story Model)
- ユーザーストーリー品質評価モデル (User Story Quality Assessment Model)
- リスク (Risk)
- リスク管理 (Risk Management)
- リリース (Release)
- リーダーによる自律性のサポート (Leader Autonomy Support)
- リーダーシップ (Leadership)
- リーダーシップギャップ (Leadership Gap)
- リーン思考 (Lean Thinking)
- レトロスペクティブゲーム (Retrospective Games)
- 一時的組織 (Temporary Organization)
- 不確実性 (Uncertainty)
- 不確実性の伝達 (Uncertainty Communication)
- 不確実性マネジメント (Uncertainty Management)
- 中断 (Interruption)
- 予測可能性 (Predictability)
- 人工知能(AI) (Artificial Intelligence)
- 仮説エンジニアリング (Hypothesis Engineering)
- 会議 (Meetings)
- 依存関係 (Dependency)
- 価値 (Value)
- 価値指向による優先順位付け (Value Oriented Prioritization)
- 偶然的不確実性 (Aleatory Uncertainty)
- 共同開発手法 (Collaborative Development Method)
- 共有アラインメント・アーティファクト (Shared Alignment Artifact)
- 共有サービス (Shared Services)
- 共有メンタルモデル (shared mental models)
- 共通ゴール (shared goal(s))
- 再優先順位付け (Reprioritization)
- 冗長性 (Redundancy)
- 分散リーダーシップ (Distributed Leadership)
- 制約マネジメント (Constraint Management)
- 創発 (Emergence)
- 動的アプリケーションセキュリティテスト (DAST)
- 動的能力 (Dynamic Capabilities)
- 協調 (Collaboration)
- 反応性 (responsiveness)
- 品質 (Quality)
- 品質機能展開 (Quality Functional Deployment, QFD)
- 問題・課題 (Problems, Challenges)
- 地理的に分散したアジャイル開発 (Geographically Distributed Agile Development)
- 垂直スライス (Vertical Slicing)
- 基本的心理的欲求 (Basic Psychological Needs)
- 境界オブジェクト (Boundary Objects)
- 境界連結 (Boundary Spanning)
- 変化・変更 (Change)
- 変更管理戦略 (Change Management Strategy)
- 変革型リーダーシップ (Transformational Leadership)
- 大規模アジャイル変革 (Large-scale Agile Transformation)
- 学習 (Learning)
- 安全なソフトウェア開発 (Secure Software Development)
- 安定性指標 (Stability Metric)
- 実用最小限のモデル (Minimal Viable Model)
- 実践コミュニティ (Communities of Practice)
- 対人関係の対立 (Interpersonal Conflict)
- 役割の明確さ (Role Clarity)
- 待ち時間 (Waiting Time)
- 心理的安全 (Psychological Safety)
- 恩恵 (Beneficence)
- 意味のある仕事 (Meaningful Work)
- 意味的統合 (Semantic Integration)
- 意思決定 (Decisions)
- 意思決定ログ (Decision Logs)
- 意思決定者 (Decision-maker)
- 技術的卓越性 (Technical Excellence)
- 技術的負債 (Technical Debt)
- 投資対効果 (Return on Investment)
- 整合された自律性 (Aligned Autonomy)
- 文化 (Culture)
- 是正アクション (Corrective Actions)
- 最小市場性機能 (Minimum Marketable Feature)
- 有効性 (Effectiveness)
- 有効性・生産性 (Effectiveness, Productivity)
- 根本原因分析 (Root Cause Analysis)
- 権限移譲 (Empowerment)
- 流出不具合 (Escaped Defects)
- 混沌の端 (Edge of Chaos)
- 測定 (Measurement)
- 特定分野のエキスパート (Subject Matter Experts)
- 理論Eと理論O (Theory E and Theory O)
- 発見 (Discovery)
- 発言 (Speaking Up)
- 直接的不確実性 (Direct Uncertainty)
- 知識基盤観 (Knowledge-Based View)
- 社会的負債 (Social Debt)
- 組織のアジャイル性 (Organizational Agility)
- 組織の両利き (Organizational Ambidexterity)
- 組織学習理論 (Organizational Learning Theory)
- 組織文化 (Organizational Culture)
- 組織的要因 (Organizational Factors)
- 経営陣のコミットメント (Management Commitment)
- 継続的アーキテクティング (Continuous Architecting)
- 継続的インテグレーション (Continuous Integration)
- 継続的インテグレーション／デプロイ (Continuous Integration / Deployment)
- 継続的デリバリー (Continuous Delivery)
- 継続的改善 (Continuous Improvement)
- 脅威モデリング (Threat Modeling)
- 脱プロジェクト化 (Deprojectification)
- 脱予算経営 (Beyond Budgeting)
- 自動化 (Automation)
- 自己決定理論 (Self-Determination Theory)
- 自律性 (Autonomy)
- 行動プロファイリング (Behavioral Profiling)
- 複雑性 (Complexity)
- 複雑性思考 (Complexity Thinking)
- 複雑性理論 (Complexity Theory)
- 複雑性科学 (Complexity Science)
- 複雑適応系 (Complex Adaptive Systems)
- 要件優先順位付け (Requirement Prioritization)
- 要件優先順位付けおよび再優先順位付け手法 (Requirement Prioritization and Reprioritization Techniques)
- 要件品質評価基準 (Requirement Quality Assessment Criteria)
- 見積り・作業規模の評価 (Estimating, Sizing)
- 計画・計画作り (Plan, Planning)
- 許容された連続性 (Forgiven Continuity)
- 認知バイアス (Cognitive Biases)
- 認知的多様性 (Cognitive Diversity)
- 認識的不確実性 (Epistemic Uncertainty)
- 調整メカニズム (Coordination Mechanisms)
- 資本の再配置 (Capital Redeployment)
- 適応力のある企業 (Adaptive Enterprise)
- 選択的形式化 (Selective Formalization)
- 重要成功要因 (Critical Success Factors)
- 間接的不確実性 (Indirect Uncertainty)
- 関係性協調理論 (Relational Coordination Theory)
- 静的アプリケーションセキュリティテスト (Static Application Security Testing)
- 顧客 (Customer)
概念 (Concepts)
Section titled “概念 (Concepts)”Scrum Core
Section titled “Scrum Core”- インクリメント (Increment)
- スクラムチーム (Scrum Team)
- スクラムチームのメンバーシップ (Scrum Team Membership)
- スクラムマスター (Scrum Master)
- ステークホルダー参加 (Stakeholder Participation)
- スプリント (Sprint)
- スプリントバックログ (Sprint Backlog)
- スプリントプランニング (Sprint Planning)
- スプリントレトロスペクティブ (Sprint Retrospective)
- スプリントレビュー (Sprint Review)
- タスク見積り (Task Estimation)
- デイリースクラム (Daily Scrum)
- バックログアイテム (Backlog Item)
- プロダクトオーナー (Product Owner)
- プロダクトバックログ (Product Backlog)
- ベロシティ (Velocity)
- ユーザーストーリー (User Story)
- 受け入れ基準 (Acceptance Criteria)
- 開発者 (Developer)
Kanban & Flow
Section titled “Kanban & Flow”- WIP制限ポリシー (WIP Limit Policy)
- カンバンボード (Kanban Board)
- プルによる投入 (Pull Transition)
- ワークフローの定義 (Definition of Workflow)
- ワークフローカラム (Workflow Column)
- 作業項目 (Work Item)
- 明示的ポリシー (Explicit Policy)
- 遷移 (Transition)