PI Planning is SAFe’s most important event — a two-day gathering of all ART teams to plan the next 8–12 weeks (typically 5 sprints).

Before PI Planning

• Help groom the team backlog (PBI prioritization and refinement)
• Coach team members on SAFe processes (especially first-timers)
• Compile previous PI velocity, completion rate, and capacity data
• Calculate team capacity (accounting for holidays, PTO, shared commitments)
• Coordinate logistics (venue, tools, participant coordination)

During PI Planning

• Facilitate team breakout sessions (timekeeping and discussion)
• Escalate blockers and dependencies to the RTE immediately
• Help the team avoid over-commitment (protect realistic planning)
• Run the Confidence Vote and collect concerns

After PI Planning

• Post PI Objectives where the team can see them (physical or digital)
• Track cross-team dependencies continuously (review at every ART Sync)
• Follow up on Owned and Mitigated ROAM risks every ART Sync
• Check PI Objective progress each sprint and flag deviations early

ART Events are the recurring synchronization points that keep all teams in the ART aligned and moving at the same cadence.

An ART is a long-lived team of Agile teams — typically 5–12 teams (50–125 people) — aligned to a shared mission and moving on the same PI cadence. It is SAFe’s fundamental delivery unit.

• The Train metaphor: it departs on schedule (PI cadence); miss it and wait for the next PI
• Stable, cross-functional membership: product, engineering, and business united as one virtual org
• Key roles: RTE, Product Manager, System Architect
• Goal: deliver a valuable increment of the solution in every PI

SAFe’s four Core Values are the foundation for every method, event, and tool in the framework.

① Alignment

All levels — portfolio, program, team — stay aligned to strategic goals. PI Planning is the primary alignment mechanism. Without alignment, teams move in different directions and value fails to reach customers.

② Built-in Quality

Quality is built into the development process from the start, not added at the end. Realized through TDD, CI/CD, and Definition of Done. Poor quality ultimately slows delivery speed.

③ Transparency

Progress, risks, issues, and failures are visible to all stakeholders at all times. Realized through Program Boards, flow metrics, and radiators. Hiding information destroys trust and delays problem detection.

④ Program Execution

Focus on actually delivering value, not on plans or documents. Working software is the primary measure of progress — the Agile Manifesto spirit applied at organizational scale.

SAFe has 10 principles. Master these 5–6 most important ones first.

WSJF is built on a simple idea: “Do the work that delivers the most value in the shortest time first.”

Practical Steps

1. Score each feature in the Program Backlog on BV, TC, RR/OE, and JS using relative comparison (Fibonacci scale: 1, 2, 3, 5, 8, 13, 20)
2. Use relative comparison — not absolute values (same thinking as Planning Poker)
3. Rank features from highest to lowest WSJF score
4. Reach team and Business Owner consensus; bring the ranked list into PI Planning
5. Continuously re-evaluate during PI execution and next PI preparation — WSJF is never “set and forget”

BV (Business Value) is the score (typically 1–10) that Business Owners assign to each PI Objective during PI Planning to reflect its strategic importance.

How It Is Used

• Business Owners score each team’s PI Objectives during PI Planning
• Teams set Planned BV; Business Owners evaluate Actual AV at PI end
• Comparing Planned BV vs. Actual AV measures Program Predictability
• 10 = strategically critical; 1 = low priority

Scrum Master’s Role

• Help the team understand business value well enough to write meaningful objectives
• Facilitate the BV scoring discussion with Business Owners
• When scores are low: explore why value is perceived as low and help revise the objective

AV (Actual Value) is the score Business Owners assign at PI end to reflect how much value was actually delivered against each PI Objective.

Consistently achieving 100% may indicate under-commitment. Analyze the gap to improve planning accuracy in the next PI.

1. Team drafts PI Objectives with clear, specific, measurable statements of what will be achieved
2. Business Owners score each objective (1–10): 10 = strategically critical, 1 = low priority
3. Team and Business Owners discuss — low scores signal a mismatch; revise the objective
4. Uncommitted Objectives are tracked separately (BV assigned but not counted in PI success criteria)
5. At PI end, evaluate AV and analyze the Planned BV vs. AV gap in I&A

The RTE (Release Train Engineer) is the Scrum Master for the entire ART — a servant leader and coach for the whole train.

Primary Responsibilities

• Facilitate all ART-level events: PI Planning, System Demo, I&A
• Remove ART-level impediments and escalate organizational blockers
• Coordinate cross-team dependencies
• Coach Scrum Masters across the ART
• Collect and visualize metrics (flow, quality, predictability)
• Manage stakeholder communication

ROAM is a framework for classifying and managing risks identified during PI Planning.

SM Facilitation Steps

1. Have everyone write risks on sticky notes (physical or digital — brainstorm format)
2. Read each risk aloud; classify into R/O/A/M as a group (vote or discuss to consensus)
3. For Owned and Mitigated risks, always assign a named owner AND a due date
4. For Accepted risks, get explicit stakeholder acknowledgment — prevents “I didn’t know” later
5. Record all risks on the ROAM board and update status at every ART Sync

1. During PI Planning, visualize dependencies on the Program Board using directional arrows
2. For each dependency, clarify the providing team and the receiving team
3. Review dependency status at every ART Sync — red arrows = unresolved risk
4. Drive red arrows (unresolved dependencies) toward zero as the primary SM goal
5. Escalate unresolvable dependencies to the RTE for organizational intervention
6. Use I&A to improve how dependencies are identified during future PI Planning events

The Program Board is a visual map created during PI Planning that shows all teams’ committed features, cross-team dependencies, and milestones for the PI.

The System Demo is an ART-wide demonstration of the fully integrated increment to stakeholders — distinct from individual Sprint Reviews because it shows the system working as a whole.

• Catches integration failures and expectation mismatches before they compound
• Gives stakeholders a regular, predictable feedback opportunity
• Validates that value is being delivered at the system level, not just team level

Inspect & Adapt (I&A) is the ART-wide retrospective and improvement event held at the end of each PI — far broader than a team-level retrospective.

Three-Part Structure

1. PI System Demo: Full ART demo of all sprints’ integrated work to Business Owners and stakeholders
2. Quantitative Problem Analysis: Review flow metrics, predictability, and quality data; perform root-cause analysis (5 Whys, fishbone)
3. Problem-Solving Workshop: Design improvement actions for specific root causes; these become inputs to the next PI Planning

The IP (Innovation & Planning) Sprint is the final sprint of each PI (typically Sprint 5), reserved for four specific purposes — not for normal feature delivery.

• It is NOT a buffer sprint for catching up on late work
• Packing feature development into the IP Sprint destroys all four of its intended values

• Explain the IP Sprint’s four purposes to prevent the team from treating it as “free time”
• Facilitate the planning of innovation activities (hackathons, experiments)
• Drive backlog refinement for the next PI Planning

SAFe uses six Flow Metrics to measure and improve the flow of value through the ART.

A CFD is a stacked area chart showing the volume of work in each state (backlog / in progress / done) over time.

• Visualize WIP in real time: widening bands = WIP is growing (bottleneck signal)
• Read throughput and lead time: the slope and horizontal span of bands reveal both
• Detect scope creep: a rising top line means scope was added
• Verify improvement effects: narrowing bands after a WIP-reduction action confirm it worked

Program Kanban is an ART-level Kanban board that visualizes feature flow and enforces WIP limits to improve flow efficiency. Features are managed here before entering team backlogs.

Jira Align is Atlassian’s enterprise Agile planning platform designed to support large-scale frameworks like SAFe.

• Unified visibility across Portfolio → Program → Team layers
• Digital PI Planning support: virtual PI Planning rooms, Program Board, and ROAM boards
• Digital Program Board: manage features, dependencies, and milestones in real time
• ROAM risk management: classify risks, assign owners, set deadlines, track resolution
• Flow metrics dashboard: real-time view of predictability, BV vs. AV, and velocity
• Jira integration: team-level Jira data flows up automatically into program-level planning

Scrum is a lightweight framework for developing and sustaining complex products iteratively and incrementally (Scrum Guide 2020).

⚠️ The right side still has value — the left side is simply valued more.

Key Principles (from the 12)

• Deliver working software early and continuously
• Welcome changing requirements, even late in development
• Business people and developers collaborate daily
• Build projects around motivated individuals; give them the environment and trust they need
• Working software is the primary measure of progress
• Maintain a sustainable pace of development
• Simplicity — the art of maximizing the amount of work NOT done — is essential
• Self-organizing teams produce the best architectures, requirements, and designs
• Teams regularly reflect on how to become more effective, then tune and adjust

Scrum is grounded in empirical process control theory (empiricism), supported by three inseparable pillars.

① Transparency

The process and work must be visible to all accountable parties. Examples: public Product Backlog, clear Definition of Done, open sprint board.

② Inspection

Scrum artifacts and progress toward goals must be inspected frequently. Examples: Sprint Review, Daily Scrum, Retrospective, backlog refinement.

③ Adaptation

If any aspect deviates beyond acceptable limits, adjust as soon as possible. Examples: backlog refinement, mid-sprint plan adjustment, Retrospective action items.

The Scrum Master is a servant leader with accountability in three directions.

• Does NOT direct or assign tasks to team members
• Does NOT decide the Sprint Goal (that belongs to the team and PO)
• Does NOT solve problems for the team — enables the team to solve their own problems
• Does NOT manage people — manages the process and environment

1. Surface them: ask “What is blocking you today?” at every Daily Scrum; maintain a visible Impediment Backlog
2. Classify: can the team resolve this themselves, or does it need external support?
3. Act: technical blockers → IT/Architect; interpersonal issues → coaching / 1-on-1; external dependencies → RTE escalation
4. Verify and prevent recurrence: confirm the impediment is truly resolved; explore root causes in the Retrospective

Servant Leadership is a style where the leader serves the team in order to maximize the team’s capability — not the other way around. Coined by Robert Greenleaf; foundational to Scrum.

How an SM Practices Servant Leadership

• “What do you think the solution is?” — ask, don’t prescribe
• Advocate within the organization to remove team-level obstacles
• Encourage the team to make decisions without needing SM approval
• Measure yourself by the team’s success, not your own visibility

Purpose: plan what to deliver and how in the coming Sprint. Time-box: 1 hour per week of Sprint length (max 4 hours for a 2-week Sprint).

• Establish the Sprint Goal before selecting backlog items — the goal is the anchor
• Confirm backlog readiness (DoR) before Sprint Planning begins
• Show actual capacity numbers to prevent over-commitment
• Confirm everyone understands and is committed before closing

• Unprepared PO: enforce backlog refinement as a non-negotiable pre-condition
• Over-commitment: show historical velocity data; help the team say “not this sprint”

Purpose: sync team progress toward the Sprint Goal in 15 minutes. Not a status report — a team-driven planning adjustment.

• Developers own the Daily Scrum; SM supports as needed
• Hard 15-minute timebox; detailed discussions move to an “after-standup” sidebar
• Monitor whether the team is talking to the Sprint Goal, not just to each other

• Do not let it become a management status report
• The SM does not need to summarize all responses — let the team own the conversation

Purpose: demonstrate the Increment to stakeholders and gather feedback. The SM supports the event so it serves its intended purpose effectively — not as the sole facilitator. Time-box: 1 hour per week of Sprint length.

• Help prepare the demo environment — confirm technically in advance
• Draw stakeholders into active discussion, not passive observation
• Verify only items meeting the DoD are included in the demo
• Support the PO in capturing feedback directly into the backlog
• Celebrate the team’s work — build a culture of recognition

Purpose: support the team in inspecting and improving their process, relationships, and tools. Time-box: 1.5 hours per week of Sprint length.

• Create psychological safety: “this is a learning space, not a blame space”
• Produce specific, actionable items with a named owner and due date
• Begin every retro by reviewing last retro’s action items — was anything done?
• Rotate formats — same format every sprint breeds disengagement

The DoR is a checklist that defines when a backlog item is considered ready to be pulled into Sprint Planning — used as a field practice rather than an official Scrum construct.

• Acceptance criteria are clearly defined
• The story is small enough for the team to estimate with confidence
• Dependencies are resolved or at least identified with a plan
• Business value is understood
• Any needed UI mocks, API specs, or data requirements are available

The DoD is a shared checklist of conditions every Increment must meet before it can be called “Done” — agreed by the team and all relevant stakeholders.

• Code is reviewed and merged to the main branch
• All automated tests (unit, integration) pass
• Documentation is updated
• Deployed and verified in a staging environment
• All acceptance criteria are satisfied
• Security scan completed (where applicable)

Velocity is the average number of story points a team completes per Sprint. It is a team-internal capacity indicator.

• Sprint Planning: sets the realistic amount of work to pull into the Sprint
• Release Planning: remaining backlog ÷ average velocity = estimated Sprints remaining
• Improvement measurement: track velocity trend after Retrospective action items

• Never make “increasing velocity” a team goal — it incentivizes quality shortcuts and burnout
• Never compare velocity across teams — estimation baselines are different and the comparison is meaningless
• Management should not set velocity targets — teams own their own capacity measurement

Stories are estimated using relative estimation — expressed in story points representing relative size, complexity, and effort, not absolute hours.

• Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is most common
• T-shirt sizes (XS / S / M / L / XL) are also used by some teams
• Establish a reference story first (“a 3-point story looks like this…”) before estimating others
• Estimating as a full team shares knowledge and surfaces hidden complexity

Planning Poker is a consensus-based estimation technique where all team members reveal their estimates simultaneously to eliminate anchoring bias.

1. PO presents and explains the story
2. Each team member privately selects an estimate card
3. All cards are revealed simultaneously — this is the critical rule
4. The highest and lowest estimators explain their reasoning
5. Discuss; repeat until consensus is reached

Story Splitting is the practice of breaking a user story that is too large for a single Sprint into smaller, independently valuable pieces.

A Burn-down Chart is a line graph showing remaining work (story points) in a Sprint over time.

• Compare the ideal line (straight diagonal) to the actual remaining-work line to assess Sprint Goal achievability
• Steady downward slope = on track; flat or rising line = a blocker or scope change has occurred
• Review the chart before every Daily Scrum and address abnormal patterns immediately

A Burn-up Chart is a two-line chart: one line showing completed work accumulating, and another showing total scope.

Lead Time is the elapsed time from when a customer request enters the backlog to when value is delivered to the customer (deployed / done).

• WIP limits: reduce in-progress volume to increase completion rate
• Batch size reduction: split large features into small pieces that can be delivered sooner
• Dependency elimination: remove wait time caused by cross-team or external blockers
• Approval flow streamlining: reduce review and sign-off wait time

Cycle Time is the elapsed time from when active work begins on an item to when it is complete.

Throughput is the number of work items completed per unit of time (e.g., per Sprint). It counts items — not story points.

• Provides an objective view of delivery capacity independent of estimation accuracy
• Feeds probabilistic forecasting models (Monte Carlo simulation)
• Core metric in “no-estimates” approaches where story points are intentionally avoided

• Sprint Planning: sets the realistic amount of work to commit to
• Release Planning: remaining backlog ÷ average velocity = Sprint count forecast
• Improvement measurement: track velocity trend after Retrospective action items
• Capacity management: adjust for team composition changes, holidays, and leave

• Do not make “increasing velocity” a team goal — incentivizes quality shortcuts
• Do not compare velocity across teams — estimation scales are not equivalent
• Velocity is a planning tool, not a performance appraisal metric

1. Do not accept the change directly: redirect the stakeholder to the PO with a clear explanation
2. Explain the Scrum rule: “The Sprint Backlog belongs to the team; mid-Sprint scope changes threaten the Sprint Goal and our commitment”
3. Route through the PO: add the request to the Product Backlog as a candidate for the next Sprint
4. For genuine emergencies only: consider Sprint cancellation or a scope trade-off (remove existing work of equal size)

Sample stakeholder communication

“We’ll add your request to the Product Backlog and discuss prioritization with the PO for the next Sprint. Changing scope mid-Sprint disrupts the team’s focus and risks breaking our current commitment.”

First: gather facts before reacting. Is this a single blip or a multi-Sprint trend? Has team composition changed? Has work complexity shifted?

Common conflict patterns: “Why does this take so long?” vs. “Please understand our technical constraints.” Or: “I want to change the requirements” vs. “Stop changing things mid-Sprint.”

1. Separate 1-on-1s: hear each side’s perspective, concerns, and expectations privately — separate fact from emotion
2. Create a joint dialogue: facilitate a safe, neutral conversation between both parties — SM stays strictly in facilitator mode
3. Anchor on shared goals: “Both of you want to deliver a great product” — use the Sprint Goal and Product Goal as neutral common ground
4. Build explicit agreement: make technical constraints visible in business language; clarify that prioritization authority rests with the PO while impact must be transparent

First, understand the resistance: belief that “the current way is fine,” fear of change, past failed Agile rollouts, distrust of “Agile in name only.”

• Ask, don’t mandate: “What pain points do you feel with our current process?” is far more effective than announcing “we’re doing Scrum now”
• Start with one experiment: try just the Daily Scrum for two weeks — “If it doesn’t help, we revert.” Lower the perceived risk
• Create visible wins: measure and share a concrete improvement so the team feels the benefit firsthand
• Build psychological safety: “failure is data, not blame” — model it yourself by sharing something you tried that didn’t work

1. Listen first: have individual conversations to understand why — do not assume or enforce attendance before hearing the reason
2. Re-explain purpose and value of each ceremony — absence often signals the event feels pointless or repetitive
3. Improve the ceremonies themselves: shorten, restructure, or change the format to make them worth attending
4. Co-create a Working Agreement that includes ceremony participation as a shared team commitment

1. Visualize all dependencies on the Program Board or a shared dependency tracker
2. Directly connect the blocked team and the providing team — facilitate a conversation, not a ticket chain
3. If unresolvable at team level, escalate to the RTE for ART-level intervention
4. Use I&A to redesign how dependencies are identified earlier in future PI Planning events
5. Use ART Sync weekly to keep all dependency statuses current

1. Listen carefully to the specific concern — “Agile = uncontrollable” is a common misunderstanding worth addressing directly
2. Reframe Agile’s value in business language: transparency, predictability, early risk detection, measurable progress at every Sprint
3. Invite the stakeholder to a Sprint Review or System Demo — experiencing working software shifts perspective more than any argument
4. Present quantitative outcome data: velocity trend, lead time reduction, defect rate, customer satisfaction
5. Partner with the RTE or Agile Coach to address organizational-level resistance systematically

1. Prioritize defect response first; then honestly assess whether the Sprint Goal is still achievable
2. Immediately inform the PO and facilitate a Sprint Backlog triage — what stays, what moves to the next Sprint?
3. Bridge the defect response team and the development team — prevent information silos and duplicated effort
4. Conduct a blameless root-cause analysis (5 Whys) in the Retrospective and design structural prevention measures

1. Start by listening — 1-on-1s and anonymous surveys before any action. Diagnose before prescribing
2. If over-commitment is the cause, move to capacity-based planning immediately — show the data
3. If uncontrolled interruptions are the cause, establish a formal protocol for handling unplanned work
4. If external pressure is the source, escalate and actively shield the team from unsustainable demands
5. Remove mandatory overtime or after-hours expectations and re-establish a sustainable pace as non-negotiable

• Standardize tools: one async channel (Slack/Teams), one video platform, one board tool — reduce friction
• Make work visible: digital Kanban board everyone can see in real time regardless of timezone
• Protect overlap time: schedule Daily Scrum in the timezone overlap window — make it sacred
• Establish async communication norms: agree on expected response times, preferred channels, and escalation paths
• Invest in periodic face-time: even quarterly in-person sessions rebuild trust in ways that no tool can replicate
• Cultivate online psychological safety: explicitly create space for questions and disagreement in async channels

1. Start with a private, non-evaluative 1-on-1 — listen to understand the situation before diagnosing
2. Identify the root cause: technical gaps, motivation issues, personal circumstances, or team relationship dynamics
3. Provide targeted support: pair programming, learning opportunities, workload adjustment, or referral to professional support
4. Escalate to management or HR only when appropriate — and ideally with the team member’s awareness

1. Make capacity data visible in every Sprint Planning — show working days, historical velocity, and current commitments side by side
2. Ask: “Does this amount of work match our last three Sprints’ actual output?” before locking any commitments
3. Explore the root cause: external pressure, perfectionism, fear of looking unproductive, or cultural expectations
4. Frame reliability as a team value: consistent delivery builds stakeholder trust far more than heroic over-commitment

• Rotate formats: same format every Sprint breeds disengagement — alternate between 4Ls, KPT, Mad/Sad/Glad, sailboat, etc.
• Make action items specific: “Improve communication” is not an action. “Run a 15-min tech sync every Tuesday” is
• Start by reviewing last retro’s actions: if nothing was done, discuss why before generating new ones
• Increase psychological safety: try anonymous sticky notes; SM shares a personal failure first to model openness
• Change the setting: offsite or informal location refreshes energy; even a different virtual background helps remotely

1. Diagnose the root cause: genuinely overloaded? Unclear on PO accountabilities? Simply not engaged?
2. Quantify the cost of PO absence: rework from ambiguous stories, team idle time, misaligned priorities — make the impact visible
3. Help the PO restructure their schedule to protect ceremony participation as a priority
4. If the situation does not improve after direct conversation, escalate to the RTE or management

• Retrospective records: accumulate learnings and action items as versioned pages — the team’s growth history
• Working Agreement: post shared team commitments where everyone can reference them anytime
• PI Objectives: maintain a living page visible to team and stakeholders throughout the PI
• Knowledge base: document recurring impediments, solutions, technical specs, and onboarding materials
• Stakeholder dashboard page: update every Sprint with Sprint Goal status, risks, and next priorities
• DoD posting: keep the team’s DoD in Confluence for easy reference before Sprint Review

• Digital PI Planning: the primary platform for running virtual PI Planning events — virtual rooms, shared boards, real-time collaboration
• Digital Program Board: manage features, dependencies, and milestones in a shared digital space
• ROAM board: classify risks, assign owners, and track resolution status
• Flow metrics dashboard: real-time view of predictability, BV vs. AV, velocity, and program health
• Portfolio alignment: trace Epic → Feature → Story hierarchy across the full ART
• ART Sync support: update cross-team dependency status, blockers, and PI Objective progress weekly

Agile dashboards should function as information radiators — anyone looking at them should immediately understand the team’s health.

• Jira built-in reports: Burn-down, velocity chart, and Sprint report cover most team-level needs out of the box
• Custom dashboard: Jira’s dashboard gadgets can display WIP count, items completed, impediment count, and DoD compliance rate
• Update cadence: refresh at minimum every Sprint — stale data is worse than no data
• Audience-aware design: a team board and an executive summary serve different needs; design for each audience

• Jira integration: connect via Power BI Connector or Jira API for auto-refreshing reports — no manual data entry
• Velocity trend: multi-Sprint velocity line chart for planning accuracy conversations
• Flow metrics visualization: lead time, cycle time, and throughput trends over rolling periods; CFD replication possible
• Cross-team analysis: multi-team and multi-PI analysis that Jira’s native reports can’t handle
• Executive reporting: business-language KPI dashboards distributed automatically to leadership

• Backlog management: Epic → Feature → User Story → Task hierarchy with prioritization and filtering built in
• Sprint board: Kanban-style board for WIP visualization; drag-and-drop Sprint Backlog management
• CI/CD pipeline: Azure Pipelines automates build, test, and deploy — directly enabling Built-in Quality
• Test management: Azure Test Plans links test cases to stories, supporting DoD verification and traceability
• Built-in reports: Sprint burn-down and Cumulative Flow Diagram are generated automatically

• Digital Program Board: build a Sprint × Team grid; add feature cards and draw dependency arrows in real time — everyone edits simultaneously
• ROAM board: have participants brainstorm risks on sticky notes, then drag them into R/O/A/M quadrants as a facilitated group activity
• Retrospectives: run 4Ls, KPT, or custom formats with distributed teams; use dot-voting for action prioritization
• PI timeline: visualize milestones, releases, and IP Sprint across the full PI visually and share with stakeholders
• Problem-Solving Workshop (I&A): run fishbone diagrams and 5 Whys analysis collaboratively in the digital space

PI（Program Increment）プランニングとは、SAFeにおける最も重要なイベントで、ARTに関わる全チームが一堂に会して、次の8〜12週間（通常5スプリント）の計画を立てる2日間のイベントです。

【PIプランニング前】

• チームバックログの整備支援（PBIの優先順位確認・リファインメント）
• チームメンバーへのSAFeプロセス教育（特に初参加者向け）
• 前PIのベロシティ・完了率などのデータ整理
• キャパシティ計算（祝日・有給・他プロジェクト稼働を考慮）
• ロジスティクス調整（会場・ツール・参加者調整）

【PIプランニング中】

• チームのブレイクアウトセッションのファシリテーション（タイムキーピング・議論促進）
• 障害・依存関係を即時RTEにエスカレーション
• チームが現実的なコミットメントをできるよう支援（過剰コミット防止）
• 信頼投票の実施と懸念事項の収集・対応

【PIプランニング後】

• PIオブジェクティブをチームに見える場所に掲示・共有
• 依存関係の継続的なトラッキング（毎週ART Syncで確認）
• Owned/MitigatedリスクをART Syncで継続追跡
• 各スプリントでPIオブジェクティブとの照合・差異の早期発見

ARTイベントとは、SAFeにおいてART全体が同期するための定期的なイベント群です。複数チームが同一ケイデンスで動き、大規模な整合性を維持します。

共通のミッションとビジョンに向かって協働する、5〜12チーム（50〜125人）の長期的な自己組織化チームの集合体です。SAFeの基本デリバリー単位です。

• 電車（Train）のメタファー：定刻（PIケイデンス）で出発し、乗り遅れたら次のPIを待つ
• 固定メンバー：プロダクト・エンジニアリング・ビジネスが一体となった仮想組織
• 主要役割：RTE（リリーストレインエンジニア）・プロダクトマネージャー・システムアーキテクト
• 継続的デリバリー：すべてのPIで価値あるソリューションを届けることを目指す

SAFeには4つのコアバリューがあります。すべての手法・イベント・ツールの基盤となる価値観です。

① Alignment（整合性）

全階層（ポートフォリオ→プログラム→チーム）が戦略目標に整合する状態。PIプランニングが主な整合メカニズムです。整合がないと、各チームが独立して動き価値が届かなくなります。

② Built-in Quality（組み込み品質）

品質は後から追加するのではなく、開発プロセスに最初から組み込む考え方。TDD・CI/CD・DoDが実践手段です。品質の欠如は最終的に速度を下げます。

③ Transparency（透明性）

進捗・リスク・課題・失敗をすべてのステークホルダーに包み隠さず可視化する。プログラムボード・フローメトリクスで実現します。隠蔽は信頼を破壊し、問題の早期発見を妨げます。

④ Program Execution（プログラム実行）

計画よりも、実際に動くプロダクトを届けることにフォーカス。「動くソフトウェアが最高の進捗報告」という精神を大規模組織で実現します。

SAFeには10の原則があります。特に重要な上位5〜6つを深く理解しておきましょう。

WSJFは「最も短い時間で最大のビジネス価値を生む仕事を最優先にする」という考え方に基づいた優先順位付け手法です。

実践手順

1. バックログの各フィーチャーを BV・TC・RR/OE・JS で相対評価する（フィボナッチ数列：1,2,3,5,8,13,20）
2. 絶対値ではなく相対比較でスコアリングする（プランニングポーカーと同じ考え方）
3. WSJF値の高い順にフィーチャーを並べ替える
4. チーム・ビジネスオーナー間で合意形成し、PIプランニングに持ち込む
5. PI実行中・次PI準備でも継続的に見直す（一度決めて終わりではない）

BV（Business Value）とは、PIプランニング中に、PIオブジェクティブそれぞれに対してビジネス側が付与する価値スコア（通常1〜10）です。

使用場面と役割

• PIプランニング中に、ビジネスオーナーがチームのPIオブジェクティブを評価する
• チームは「計画BV（Planned BV）」を設定し、ビジネス側が「実績AV（Actual AV）」を評価する
• PI終了後にPlanned BV vs Actual BVを比較し、プログラム予測精度を測定する
• 10点＝戦略的に最重要、1点＝あれば良いが優先度低

スクラムマスターの役割

• チームがビジネス価値を理解してオブジェクティブを設定できるよう支援する
• BVスコアの根拠をステークホルダーから引き出すファシリテーションを行う
• スコアが低い場合→なぜ価値が低いか理解し、オブジェクティブを修正する

AV（Actual Value）とは、PI終了時にビジネス側が評価する、PIオブジェクティブの実際の達成価値スコアです。

予測精度が常に100%の場合は過小コミットしている可能性があります。差分を分析して次PIの精度向上につなげましょう。

1. チームがドラフトのPIオブジェクティブを作成する（「何を達成するか」を具体的・測定可能な形で記述）
2. ビジネスオーナーがBVを付与する（1〜10点）：10点＝戦略的最重要、1点＝優先度低
3. チームとビジネスオーナーが対話する（スコアが低い場合はオブジェクティブの修正を検討）
4. Uncommitted Objectivesは別管理（BVは付与するが達成できなくてもPIの成否に影響しない）
5. PI終了時にAVを評価し、Planned BV vs AVの差分をI&Aで分析する

RTE（Release Train Engineer）とは、ARTレベルのスクラムマスターであり、ART全体のコーチ・ファシリテーターです。

主な責務

• PIプランニング・システムデモ・I&AなどARTイベントのファシリテーション
• ART全体の障害除去とエスカレーション
• 複数チーム間の依存関係調整
• チームのスクラムマスターへのコーチング
• メトリクス収集と可視化（フロー・品質・予測精度）
• ステークホルダー管理とコミュニケーション

ROAMとは、PIプランニング中に特定されたリスクを4つのカテゴリに分類し、対応方針を合意するフレームワークです。

SMのファシリテーション手順

1. 付箋またはデジタルボードでリスクを全員が書き出す（ブレインストーミング形式）
2. 1つずつ声に出して読み上げ、全体で4分類に仕分ける
3. O・Mのリスクには「誰が・いつまでに」を必ずセットで決める
4. Acceptedのリスクはビジネスオーナーに明示的に同意を取る
5. 全リスクをROAMボードに記録し、ART Syncで毎週ステータスを更新する

1. PIプランニング中にプログラムボードで依存関係を矢印で可視化する
2. 各依存関係に「提供チーム」と「受け取りチーム」を明確にする
3. 毎週のART Sync（スクラム・オブ・スクラム）で進捗と障害を確認する
4. 赤い矢印（未解決の依存関係）をゼロに近づけることを目標にする
5. 解消できない依存はRTEを通じてエスカレーションし、組織的に対処する

プログラムボードは、PIプランニングのアウトプットとして作成される、複数チームのフィーチャーと依存関係を可視化したボードです。

システムデモとは、ART全体で統合されたインクリメントをステークホルダーにデモする場です。各チームのスプリントレビューとは異なり、「全チームの成果を統合した状態」でデモします。

• 個別チームが順調でも統合すると動かない・期待した価値になっていないことを早期発見できる
• ステークホルダーの早期フィードバック獲得に有効

Inspect & Adapt（I&A）は、PI終了後に行うART全体の振り返りと改善の場です。単なるレトロスペクティブではなく、ART全体・システム全体・進め方全体を見直します。

3部構成で実施

1. PI System Demo：PI全体の統合デモ。全スプリントの成果を統合した状態でステークホルダーにデモする
2. 定量的問題分析：フローメトリクス・予測精度・品質指標を確認。根本原因分析（5 Why等）を実施する
3. 改善ワークショップ：特定した課題に対して改善アクションを策定。次PIへの入力とする

IP（Innovation & Planning）スプリントとは、PIの最後のスプリント（通常スプリント5）のことです。通常の開発作業は行わず、4つの目的のために使います。

• 「作業が遅れたときに埋め合わせるバッファスプリント」ではない
• IPスプリントに機能開発を詰め込むと本来の4つの価値がすべて失われる

• チームがIPスプリントを「休息週間」にしないよう意義を説明する
• 革新アクティビティ（ハッカソン等）の企画ファシリテーションを行う
• 次PIプランニングに向けたバックログリファインメントを推進する

SAFeでは6つのフローメトリクスを用いて、価値の流れを測定・改善します。

CFD（Cumulative Flow Diagram）とは、バックログ・進行中・完了の各ステータスにある作業量を時系列で積み上げ表示したグラフです。

• WIPの増減をリアルタイムで可視化：帯の幅が広がっている＝WIPが増えている（ボトルネックのサイン）
• リードタイムの変化：帯の傾き角度でスループットと平均リードタイムを把握する
• スコープ変化の検知：上端のラインが急に上がる場合はスコープ追加が発生している

プログラムカンバンとは、ARTレベルでフィーチャーの流れを可視化し、WIPを制限してフロー効率を高めるカンバンボードです。チームバックログに入れる前段階のフィーチャー管理ツールです。

Jira Alignとは、SAFeのような大規模アジャイルフレームワークを支援するエンタープライズ向けポートフォリオ管理ツールです（Atlassian社製）。

• ポートフォリオ→プログラム→チームの3階層を一元管理できる
• デジタルPIプランニングのサポート：オンラインPIプランニングで主要ツールとして活用
• プログラムボードのデジタル化：依存関係・マイルストーン・フィーチャーをリアルタイム管理
• ROAMリスクの管理：リスクの分類・担当者アサイン・進捗追跡
• フローメトリクスのダッシュボード：予測精度・BV vs AV・ベロシティをリアルタイム表示
• Jiraとの統合：チームレベルのJiraデータを上位計画に自動反映

スクラムとは、複雑な問題に対応するためのフレームワークで、価値の高いプロダクトを反復的・漸進的に届けます（スクラムガイド2020）。

⚠️ 右辺も重要ですが、左辺をより重視するという意味です。

12の原則（特に重要なもの）

• 価値あるソフトウェアを早く継続的に届ける
• 要件変更を歓迎する（たとえ開発後期でも）
• 動くソフトウェアを数週間〜数ヶ月ごとに届ける
• ビジネスと開発者は毎日協働する
• 信頼できる人々に環境と支援を与え、仕事を任せる
• 動くソフトウェアが進捗の主要な尺度
• 持続可能なペースで開発を継続
• シンプルさ（やらない作業量を最大化すること）
• 自己組織化チームが最良のアーキテクチャ・要件・設計を生む
• 定期的にチームの効果を振り返り調整する

スクラムは経験的プロセス制御理論（経験主義）に基づいており、3つの柱で支えられています。

① 透明性（Transparency）

プロセスと作業を担当者全員が見える状態にします。実践例：プロダクトバックログの公開・DoDの明確化・スプリントボードのオープン化

② 検査（Inspection）

アーティファクトと目標達成の進捗を頻繁に検査します。実践例：スプリントレビュー・デイリースクラム・レトロスペクティブ

③ 適応（Adaptation）

問題が発見されたらプロセスや成果物を調整します。実践例：バックログリファインメント・スプリント中の計画修正・レトロのアクション実施

スクラムマスターはサーバントリーダーとして、3方向に対して責務を持ちます。

• チームメンバーへの指示・命令はしない
• タスクのアサインはしない（チームが自己組織化して行うこと）
• スプリントゴールの決定は自分ではしない（チームとPOの仕事）
• チームの代わりに問題を解決しない（チームが自律的に解決できるよう支援する）

1. 可視化：デイリースクラムで「今日の障害は何か？」を確認。障害リスト（Impediment Backlog）を作成・全員に公開する
2. 分類：チーム内で解決可能か？チーム外の支援が必要か？を判断する
3. 対応：技術的な問題→IT部門・アーキテクトへ連絡、人間関係→コーチング・1on1、外部依存→RTE経由で組織調整
4. 追跡と完了確認：障害が実際に解消されたか確認する。再発防止のためレトロスペクティブで根本原因を議論する

サーバントリーダーシップとは、リーダーがチームに「奉仕する」ことで、チームの能力を最大化するリーダーシップスタイルです。Robert Greenleafが提唱し、スクラムの根幹にある考え方です。

スクラムマスターとしての実践

• “どうすれば解決できると思う？” と問いかける（答えを与えない）
• チームの障害を取り除くために組織に働きかける
• 自分の「承認」を必要としない意思決定をチームに促す
• チームの成功を自分の成功と捉える

目的：スプリントで「何を」「どうやって」届けるかを計画する。タイムボックスは1スプリント1時間/週が目安（2週間スプリントなら最大4時間）。

• スプリントゴールを最初に確定する
• バックログアイテムの整備はプランニング前に完了させておく（DORの確認）
• キャパシティを数値で提示し、過剰コミットを防ぐ
• 全員が理解・コミットしているかを確認してから終了する

• POが未準備：事前のバックログリファインメントを徹底する
• チームが過剰コミット：実績ベロシティを見せてリアルな計画に誘導する

目的：15分以内でスプリントゴールに向けた進捗を同期する。進捗報告会ではなく、チームが計画を自律的に調整するための場。

• デイリースクラムの主体はDevelopers。SMは必要に応じてファシリテーションを支援する
• 時間を守る（15分厳守）。詳細な議論は「アフタースクラム」に誘導する
• チームがゴールを意識して話せているかを確認する

• 進捗報告会にしない（マネジメントへの報告の場ではない）
• SMがすべての発言を整理・まとめる必要はない

目的：インクリメントをステークホルダーに披露し、フィードバックを得る。SMはイベントが目的に沿って効果的に行われるよう支援・ファシリテートする。タイムボックスは1スプリント1時間/週が目安。

• デモ環境の準備支援（技術的な準備はチームと協力して事前に確認しておく）
• ステークホルダーを積極的に議論に参加させる（一方的なプレゼンにしない）
• 「完成」の定義（DoD）に合致しているかを確認する（未完了は含めない）
• フィードバックをバックログに反映するようPOを支援する
• チームの努力を認め、祝う文化を醸成する

目的：チームがプロセス・関係性・ツールを改善する場を支援・ファシリテートする。タイムボックスは1スプリント1.5時間/週が目安。

• 心理的安全性の確保：「これは批判の場ではなく学びの場」と明示する
• 具体的なアクションアイテムの合意：担当者・期日付きで決める
• 前回のアクションの振り返り：「実施できたか？」を最初に確認する

DoR（Definition of Ready）とは、バックログアイテムがスプリントプランニングに持ち込める状態になったかを判断するための現場プラクティスです。

• 受け入れ基準（Acceptance Criteria）が明確に定義されている
• チームが見積もりできる粒度まで分解されている
• 依存関係が解消されている（または計画されている）
• ビジネス価値が明確になっている
• UIモックアップ・API仕様など必要な情報が揃っている

DoD（Definition of Done）とは、プロダクトインクリメントが「完成した」と言えるための条件リストです。チームとステークホルダー全員が合意している必要があります。

• コードがレビュー済みでメインブランチにマージされている
• 自動テスト（ユニット・統合）がすべてパスしている
• ドキュメントが更新されている
• ステージング環境でデプロイ・動作確認済み
• 受け入れ基準をすべて満たしている

ベロシティとは、チームが1スプリントで完了するストーリーポイントの平均値です。チームの生産能力の内部指標として使用します。

• スプリントプランニング：次スプリントで取り込めるポイント数の基準として使用する
• リリース計画：残バックログ ÷ 平均ベロシティ ＝ 残スプリント数を予測する
• 改善施策の効果測定：レトロの改善アクション後のベロシティ変化を確認する

• ベロシティを「上げること」を目標にしない→品質低下・燃え尽きの原因になる
• チーム間のベロシティ比較に使わない→見積もり基準が異なるため意味がない
• 管理者がベロシティを「目標値」として設定すべきではない

ストーリーの見積もりには相対見積もりを使います。絶対時間（時間・日数）ではなく、ストーリーポイント（相対的な複雑さ・労力）で表現します。

• フィボナッチ数列（1, 2, 3, 5, 8, 13, 21）が最もよく使われる
• Tシャツサイズ（XS/S/M/L/XL）を使うチームもある
• まず「基準ストーリー（例：3ポイント＝このくらいの規模）」を決めてから見積もりを始める
• チーム全員で見積もることでナレッジを共有できる

プランニングポーカーとは、チーム全員がカードを同時に開示することで合意形成バイアスを排除し、全員の意見を均等に反映する見積もりゲームです。

1. POがストーリーを説明する
2. 全員が見積もりカードを選ぶ（まだ見せない）
3. 全員が同時にカードを開示する（同時開示が最重要ポイント）
4. 最高値・最低値のメンバーが理由を説明する
5. 議論した後、再度見積もりを実施する（合意するまで繰り返す）

ストーリー分割とは、大きすぎるユーザーストーリーを、1スプリントで完了できる小さな単位に分割するテクニックです。

バーンダウンチャートとは、スプリント期間中に残っている作業量（ストーリーポイント）を時系列で表示した折れ線グラフです。

• 理想線（直線）と実際の残作業線を比較してスプリントゴール達成可能性を判断する
• 右肩下がりの曲線が理想（毎日作業が減っている）
• 横ばいや上昇が続く場合は障害・スコープ追加が発生しているサイン

バーンアップチャートとは、完了した作業量（ストーリーポイント）とスコープ合計を時系列で表示した2本のグラフです。

リードタイムとは、顧客がリクエストを出した時点（バックログに入った時点）から、価値が顧客に届く（デプロイ・完了）までの経過時間です。

• WIP制限：仕掛中の作業量を減らして完了速度を上げる
• バッチサイズ削減：大きなフィーチャーを小さく分割して早く届ける
• 依存関係解消：待ちの時間を減らす
• 承認フロー短縮：レビュー・承認にかかる待ち時間を削減する

サイクルタイムとは、実際に作業を開始した時点から完了するまでの経過時間です。

スループットとは、一定期間（例：1スプリント）に完了した作業アイテムの数です。ストーリーポイントではなく「アイテム数」で測ります。

• チームの生産性を客観的に把握できる
• 予測モデル（モンテカルロシミュレーション）の入力データとして使用できる
• ポイント見積もりを使わない「ノーエスティメーション」アプローチで活用される

• スプリントプランニング：次スプリントで取り込めるポイント数の基準として使用する
• リリース計画：残バックログ ÷ 平均ベロシティ ＝ 残スプリント数を予測する
• 改善施策の効果測定：レトロの改善アクション後のベロシティ変化を確認する
• キャパシティ管理：メンバー変更・休暇等によるベロシティ変動を計画に反映する

• ベロシティを「上げること」を目標にしない：品質低下・燃え尽きの原因になる
• チーム間のベロシティ比較に使わない：見積もり基準が異なるため意味がない

1. 変更を直接受け取らない：必ずPOを通じて対処するよう丁寧に伝える
2. スクラムのルールを説明：「スプリントバックログはチームのもの。スプリント中の変更は原則禁止です」と伝える
3. POへの橋渡し：追加要求をプロダクトバックログに追加し、次スプリントの候補として検討する
4. 緊急の場合のみ：スプリントキャンセルまたはトレードオフ（既存作業を外す）を検討する

ステークホルダーへのコミュニケーション例

「ご要望はプロダクトバックログに追加し、次スプリントの候補として検討します。今スプリントの変更はチームの集中を妨げ、コミットを守れなくなるリスクがあります。」

まず事実確認（パニックにならない）：急落は1スプリントだけか、複数継続しているか？チームの人数に変化はあったか？

よくある対立パターン：「なぜこんなに時間がかかるのか」vs「技術的制約を理解してほしい」、「要件を変えたい」vs「今さら変えないでほしい」

1. 個別ヒアリング：双方の立場・懸念・期待を別々に聞く。感情論ではなく、事実と影響を整理する
2. 対話の場を設定：双方が安心して話せる中立的な場を作る。SM自身は判定者ではなく、ファシリテーターに徹する
3. 共通ゴールを確認：「両者とも良いプロダクトを届けたい」という共通点を強調する
4. 合意の形成：技術的制約をPOが理解できる言葉で可視化。優先順位の意思決定権はPOにあることを明確にしつつ、影響を透明に伝える

抵抗の根本原因を理解する：「今のやり方で問題ない」という信念・変化への不安・過去のアジャイル導入失敗経験・「名ばかりアジャイル」への不信感など

• 強制しない・問いかける：「今のプロセスでどんな課題を感じていますか？」
• 小さな実験から始める：まずデイリースクラムだけ。「2週間だけ試して、効果がなければ元に戻す」と約束する
• 成功体験を作る：小さな改善を「見える化」して、チームが変化のメリットを体感できるようにする
• 心理的安全性の確保：「失敗しても責めない」文化を構築。実験・学習・改善のサイクルを繰り返す

1. 参加しない理由を個別にヒアリングする（強制的に解決しない。まず「聴く」）
2. セレモニーの「目的と価値」を改めて説明する（形式的に感じている可能性がある）
3. セレモニーの内容・時間・進め方を改善する（「何を得られるか」が見えていないとき）
4. チームで「作業協定（Working Agreement）」を作り、参加を共通ルール化する

1. プログラムボードまたはスクラム・オブ・スクラムで依存関係を可視化する
2. ブロックされているチームと提供側チームを直接つなぎ、対話を促進する（チケットのやり取りではなく直接会話）
3. 解消できない場合はRTEにエスカレーションし、組織レベルで対処する
4. 再発防止策として、PIプランニング時の依存関係の洗い出し精度を向上させる
5. ART Syncを活用してクロスチームの依存関係を毎週確認する

1. ステークホルダーの懸念を丁寧にヒアリングする（「アジャイル＝管理できない」という誤解が多い）
2. アジャイルの透明性・予測可能性・早期リスク発見のメリットをビジネス言語で説明する
3. スプリントレビューやシステムデモに招待し、実際の成果を体感してもらう
4. 定量的な成果データ（ベロシティ・リードタイム・品質指標）を提示する
5. RTEやアジャイルコーチと連携し、組織変革を支援する

1. まず障害対応を最優先させ、スプリントゴールの達成可否を正直に判断する
2. POに状況を即時報告し、スプリントバックログのトリアージ（優先順位の再設定）を支援する
3. 障害対応チームと開発チームのコミュニケーションを橋渡しする
4. レトロスペクティブで根本原因を分析（5 Whyを活用）し、再発防止策を立案する

1. 1on1や匿名アンケートでチームの状態を把握する（まず「聴く」）
2. 過剰コミットが原因なら、キャパシティに基づいた現実的な計画に修正する
3. 割り込みや緊急対応が多い場合、バッファを確保するか優先順位ルールを明確化する
4. 業務外学習の強制がある場合は排除し、持続可能なペースを守る
5. SMが組織に対して「チームへの過剰な負荷」を明示し、シールド（防波堤）の役割を果たす

• ツールの統一：Slack・Teams・Zoom等のコミュニケーションチャンネルを一本化する
• 作業の見える化：Jiraやデジタルカンバンボードで全員が進捗を確認できる状態にする
• オーバーラップ時間の確保：タイムゾーンが異なる場合、全員が参加できる時間帯をデイリースクラムに設定する
• 非同期コミュニケーションのルール化：回答期待時間・形式・チャンネルを事前に合意する
• 定期的な顔合わせ：可能であれば四半期に一度の対面（またはPIプランニング時）を実施する
• 心理的安全性の構築：オンラインでも「発言しやすい」文化を意識的に作る

1. まず1on1で個人の状況・悩み・障害を聴く（評価・批判しない。SMは評価者ではなくコーチ）
2. パフォーマンス低下の原因を特定する（技術的問題・モチベーション・個人的な事情・チームとの関係性）
3. 原因に応じたサポートを提供する（学習機会・ペアプログラミング・業務調整等）
4. 改善が見られない場合は、マネージャーや人事との連携を検討する

1. 実際のキャパシティ（稼働日数・ベロシティ実績）を数値で可視化する
2. スプリントプランニングで「このポイント数は過去の実績から見て現実的か？」を問いかける
3. 過剰コミットが繰り返される原因（外部からのプレッシャー・完璧主義等）を探る
4. 「コミットメントを守ること」の価値をチームと共有する（信頼性の積み上げが長期的な評価に繋がる）

• フォーマットを変える：毎回同じ形式では飽きる。Start/Stop/Continue → 4Ls → Mad/Sad/Gladと変えてみる
• アクションを小さく具体的にする：「コミュニケーションを改善する」でなく「毎週火曜に15分の技術共有をする」
• 前回のアクションを確認する：「やった・やれなかった」を最初に確認することで継続性が生まれる
• 心理的安全性を高める：匿名付箋の活用・SMが最初に「自分の失敗」を共有する
• 時間帯・場所を変える：オフサイトやカジュアルな場での開催も効果的

1. POの状況を把握する（多忙で物理的に参加できない？役割を理解していない？）
2. POの関与がない場合の「コスト」を可視化する（手戻り・手待ち・方向性のズレのリスク）
3. POのセレモニー参加に向けた具体的なスケジュール調整を支援する
4. それでも改善しない場合、RTEまたはマネジメントにエスカレーションする

• レトロスペクティブの記録：毎スプリントの学びとアクションをページとして蓄積する
• チームの作業協定（Working Agreement）の掲示：全員がいつでも参照できる場所に公開する
• PIオブジェクティブの共有：チーム内外に見える形で掲示・更新する
• ナレッジベース：よくある障害と解決策・技術ドキュメントを文書化する
• ステークホルダー向けプロジェクト状況ページ：スプリント進捗・リスク・次アクションを定期更新する
• DoDの掲示：チームのDoDをConfluenceで管理し、スプリントレビュー前に参照できるようにする

• デジタルPIプランニング：オンラインPIプランニングで主要ツールとして活用する
• デジタルプログラムボードの管理：フィーチャー・依存関係・マイルストーンをデジタルで可視化
• ROAMリスクの管理：リスクの分類・担当者アサイン・期限設定・進捗追跡を一元管理する
• フローメトリクスのダッシュボード：予測精度・BV vs AV・フローベロシティをリアルタイムで確認
• ポートフォリオ管理：エピック→フィーチャー→ストーリーの階層整合をJiraと連動して管理する
• ART Syncのサポート：クロスチームの依存関係・障害・PIオブジェクティブの進捗を毎週更新する

アジャイルダッシュボードは、チームの状態とプロセスを一目で把握できる「情報ラジエーター」として機能させることが重要です。

• Jiraのビルトインレポート活用：バーンダウン・ベロシティ・スプリントレポートを活用する
• カスタムダッシュボード：WIP・完了数・障害数・スプリントゴール達成率を一覧表示する
• 更新頻度：スプリント毎に必ず更新し、最新の状態を維持する
• 閲覧者を意識した設計：チーム向けと経営層向けは必要な情報が異なる

• Jiraとの連携：Power BIコネクタまたはAPIでJiraデータを取得し、レポートを自動更新できる
• ベロシティトレンド：複数スプリントのベロシティ推移を折れ線グラフで可視化する
• フローメトリクスの可視化：リードタイム・サイクルタイム・スループットのトレンド表示
• クロスチーム分析：複数チーム・複数PIをまたいだ横断分析がJira単独より容易に実施できる
• ステークホルダー向けレポート：経営層向けにKPIを分かりやすく視覚化して自動配信する

• バックログ管理：エピック・フィーチャー・ユーザーストーリー・タスクを階層管理できる
• スプリントボード：カンバンボードでWIPを可視化。スプリントバックログをドラッグ&ドロップで管理する
• CI/CDパイプライン：Azure Pipelinesでビルド・テスト・デプロイを自動化（Built-in Quality（組み込み品質）の実現に直結）
• テスト管理：Azure Test Plansでテストケースを管理し、DoDの達成を追跡する
• レポート：ビルトインのスプリントバーンダウン・累積フロー図（CFD）を活用する

• デジタルプログラムボード：スプリント×チームのグリッドを作成し、フィーチャーカードと依存関係の矢印をリアルタイムで可視化する
• ROAMリスクボード：付箋で洗い出したリスクを4象限（R/O/A/M）に分類するファシリテーションに使用する
• レトロスペクティブ：4Ls・KPT等のテンプレートで分散チームのレトロを実施する
• タイムライン作成：PI全体のマイルストーンをタイムライン形式で可視化する
• ブレインストーミング：付箋＋投票機能で参加者の意見収集と優先順位付けを効率化する