Skip to main content

Roadmapping

Roadmaps provide a flexible way to create, view, and present future plans showing important portfolio item delivery milestones to both external and internal audiences. Roadmaps keep teams updated on strategic direction, align stakeholders on priorities and timing, and provide context for planning decisions.

What Are Roadmaps?​

Roadmaps show all portfolio items at every level of your project tree, providing visibility into planned delivery across time. Both Board and Timeline layouts stay in sync with your plans because they're based on the planned start and end dates of existing portfolio items.

Roadmaps support:

  • Team alignment: Teams stay informed on the broader context and strategic direction
  • Stakeholder communication: Stakeholders understand current priorities, timing, and delivery expectations
  • Planning feedback: Planning cycles benefit from visibility into how new requests compare with existing priorities
  • Communicate plans: Present delivery schedules to external and internal audiences

Roadmap Layouts​

Choose between two layout options based on your planning and communication needs.

Board Layout​

Use the Board layout to focus on planned delivery organized by time periods.

The Board layout displays portfolio items in configurable columns representing time periods (weeks, months, quarters, or years). This view makes it easy to see what's planned for delivery in each time period and quickly communicate upcoming milestones.

Best for:

  • Communicating delivery commitments to stakeholders
  • Planning releases and milestones
  • Organizing work by time-based deliverables
  • Quick updates on what's coming in each time period

Timeline Layout​

Use the Timeline layout to see the duration of work and understand scheduling over time.

The Timeline layout shows portfolio items plotted across a continuous timeline with bars indicating start and end dates. This view helps you analyze workload distribution, identify scheduling conflicts, and adjust delivery plans by dragging items along the timeline.

Best for:

  • Analyzing workload and capacity over time
  • Understanding dependencies and scheduling conflicts
  • Adjusting dates by dragging portfolio items
  • Viewing historical delivery of portfolio items
  • Tracking organizational velocity with rolled-up estimates

The Timeline opens with a red vertical line centered on the current date, clearly showing past and future work.

Key Capabilities​

Customize views: Switch between layouts, apply filters, configure grouping and columns, and save custom views for different audiences.

Add portfolio items: Create new portfolio items directly on the roadmap using quick-add or detailed entry methods.

Update dates: Drag and drop portfolio items to adjust planned delivery dates in either Board or Timeline layout.

Save configurations: Save roadmap views with specific filters, layouts, and settings for reuse by your team.

Publish and share: Publish roadmaps to URLs that can be shared with stakeholders who don't have system access.

Export to PDF: Generate PDF versions of roadmaps for presentations and offline sharing.

Use Cases​

Executive Quarterly Business Review Roadmap​

Scenario: Product VP needs to present Q2-Q4 delivery roadmap to CEO and board of directors showing major feature releases across 3 product lines.

Approach:

Phase 1: Configure roadmap for executive audience

  1. Navigate to Portfolio → Roadmap.
  2. Switch to Board layout (easier for executives to read).
  3. Configure view:
    • Group By: Product Line
    • Show: Epics only (hide feature-level detail)
    • Columns: Months (April 2025 - December 2025)
    • Filter: Status = Committed or In Progress
  4. Apply filter to show only major initiatives:
    • Business Value ≥ 500 points
    • Strategic Theme = "Market Expansion" OR "Platform Modernization"
  5. Result: 18 high-value epics displayed across 3 product lines.

Phase 2: Adjust for visual clarity

  1. Review Board columns: April shows 8 epics (too crowded).
  2. Drag 3 lower-priority April epics to May column.
  3. Update planned end dates to reflect new schedule.
  4. Enable "Show Dependencies" to highlight cross-product line dependencies.
  5. Add roadmap title: "Q2-Q4 2025 Strategic Delivery Roadmap".
  6. Add description: "18 major initiatives delivering $4.2M business value".

Phase 3: Save and export

  1. Click Save View.
  2. Name: "Executive QBR Q2-Q4 2025".
  3. Make visible to: Executive Team.
  4. Click Export to PDF.
  5. PDF generated showing:
    • 9 months of planned delivery (April-December)
    • 18 epics organized by product line
    • Dependencies visualized
    • Business value indicated by tile color intensity
  6. Add PDF to quarterly business review presentation deck.

Phase 4: Present and gather feedback

  1. During QBR, CEO asks: "Can we move Cloud Migration epic to Q3 instead of Q4?".
  2. Open roadmap on projector (real-time collaboration).
  3. Drag "Cloud Migration" epic from December column to September column.
  4. System updates planned dates automatically.
  5. Dependencies show: "Container Platform" must complete first (still in October).
  6. Decision: Move Container Platform to August, Cloud Migration to October.
  7. Adjustments made in real-time during meeting.

Outcome: Executive stakeholders aligned on delivery roadmap, 2 epics rescheduled based on feedback, roadmap PDF distributed to board members (30 stakeholders), no follow-up meetings needed to clarify delivery plan.

Product Planning with Feature-Level Timeline View​

Scenario: Product Manager planning next 6 months of mobile app development, needs to visualize feature delivery timing and identify capacity conflicts across 4 teams.

Approach:

Phase 1: Open timeline view with feature detail

  1. Navigate to Portfolio → Roadmap.
  2. Switch to Timeline layout.
  3. Configure view:
    • Group By: Team (shows 4 mobile teams)
    • Show: Features (hide epics, show feature-level detail)
    • Timeline: January 2025 - June 2025 (6 months)
    • Filter: Product Line = Mobile App
  4. Result: 47 features plotted on timeline across 4 teams.

Phase 2: Identify scheduling conflicts

  1. Timeline view reveals:

    • Team A: 8 features scheduled in March (capacity overload)
    • Team B: Only 2 features in May-June (underutilized)
    • Team C: 3 features all starting on same date (March 1)
    • Team D: Feature "Offline Mode" scheduled May 1-15, but dependency "API Gateway" ends May 20 (conflict)

  2. Enable "Show Estimates" overlay:

    • Team A March workload: 120 points (capacity: 80 points per month)
    • Confirmed: 50% overcommitment.

Phase 3: Rebalance workload

  1. Drag 3 features from Team A March → April.
  2. System updates start/end dates automatically.
  3. Drag 2 features from Team C → Team B (May-June timeframe).
  4. Update team assignments for moved features.
  5. Check dependencies: "Offline Mode" dependency on "API Gateway" still shows conflict.
  6. Drag "Offline Mode" start date from May 1 → May 20 (after dependency completes).
  7. Dependency line now shows green (satisfied).

Phase 4: Validate capacity with rolled-up estimates

  1. Enable "Show Velocity" option (shows cumulative estimate points per month per team).
  2. Verify Team A capacity:
    • January: 75 points
    • February: 80 points
    • March: 85 points (now within 80-90 capacity range after rebalancing)
    • April: 78 points ✓
  3. All teams now operating within 75-90 point capacity range per month.

Phase 5: Save and share with teams

  1. Click Save View.
  2. Name: "Mobile App 6-Month Feature Roadmap".
  3. Make visible to: Mobile Teams, Mobile Leadership.
  4. Click Publish.
  5. Generate public URL (no login required).
  6. Share URL in Slack channel: "Updated roadmap after capacity planning session".
  7. Teams can view but not edit published roadmap.

Outcome: 47 features rebalanced across 4 teams and 6 months, 1 dependency conflict resolved, all teams operating within capacity, stakeholders can access current roadmap via published URL, no manual PowerPoint maintenance required.

Cross-ART Dependency Visualization for PI Planning​

Scenario: SAFe Release Train Engineer preparing for PI Planning event, needs to visualize dependencies between 5 Agile Release Trains (ARTs) delivering 12 epics over next PI (10 weeks).

Approach:

Phase 1: Configure roadmap for PI Planning context

  1. Navigate to Portfolio → Roadmap.
  2. Switch to Timeline layout.
  3. Configure view:
    • Group By: ART (custom field showing 5 ARTs)
    • Show: Epics and Features
    • Timeline: PI-3 (March 1 - May 10, 2025, 10 weeks)
    • Filter: Target PI = PI-3
  4. Enable "Show Dependencies" (critical for PI Planning).
  5. Result: 12 epics, 58 features across 5 ARTs displayed with dependency lines.

Phase 2: Identify cross-ART dependencies before PI Planning

  1. Review dependency lines:

    • Critical path identified: ART 1 "API Platform" epic → blocks 4 epics in ARTs 2, 3, 4
    • Broken dependency: ART 3 "Mobile App" epic scheduled Weeks 1-5, but upstream dependency ART 2 "Backend Services" not starting until Week 4 (conflict)
    • Circular dependency detected: ART 4 depends on ART 5, ART 5 depends on ART 4 (needs resolution)

  2. Zoom into critical path (API Platform):

    • Expand to show features under API Platform epic
    • Feature "Authentication API" (Weeks 1-3) blocks 8 downstream features across 3 ARTs
    • Feature must complete before PI Planning to avoid blocking entire PI.

Phase 3: Resolve scheduling conflicts

  1. Broken dependency (Mobile App):

    • Drag Mobile App epic start date from Week 1 → Week 4.
    • Dependency line turns from red (broken) to yellow (at risk) to green (satisfied).
    • Add 1-week buffer: Move start to Week 5 (safer).

  2. Circular dependency (ART 4 ↔ ART 5):

    • Open dependency details.
    • Identify: ART 4 "Reporting Engine" depends on ART 5 "Data Warehouse".
    • ART 5 "Analytics Dashboard" depends on ART 4 "Reporting Engine".
    • Resolution: Break circular dependency by completing Data Warehouse features in Weeks 1-5, then Reporting Engine Weeks 6-8, then Analytics Dashboard Weeks 9-10.
    • Adjust timeline accordingly, remove circular dependency link.

  3. Critical path (API Platform):

    • Escalate to leadership: API Platform epic must start in Week 0 (before PI).
    • Add risk flag: "Critical path blocker if not started by Feb 25".

Phase 4: Export for PI Planning event

  1. Save view: "PI-3 Cross-ART Dependency Roadmap".
  2. Export to PDF:
    • Full-page width timeline
    • All 5 ARTs visible
    • Dependencies shown with color-coded lines
    • Risk flags highlighted
  3. Print large format (36" x 24") poster for PI Planning war room.
  4. Also publish to URL for digital display on screens.

Phase 5: Use during PI Planning

  1. Display roadmap on large screen in PI Planning room.
  2. As teams commit to work, update roadmap in real-time:
    • Adjust epic and feature dates based on team capacity discussions
    • Add newly identified dependencies as teams coordinate
    • Drag features between ARTs if team assignments change
  3. Dependency lines update automatically, showing new conflicts immediately.
  4. By end of Day 2, roadmap shows fully validated PI-3 plan with all dependencies satisfied.

Outcome: 12 epics and 58 features across 5 ARTs scheduled for PI-3, 1 critical path identified and mitigated before event, 1 broken dependency resolved, 1 circular dependency eliminated, 100+ attendees aligned using visual roadmap, digital and physical roadmap artifacts created for ongoing reference.

Public Stakeholder Roadmap for Customer Communication​

Scenario: SaaS company needs to communicate product roadmap to customers showing upcoming features over next 12 months without exposing internal planning details.

Approach:

Phase 1: Create customer-facing view

  1. Navigate to Portfolio → Roadmap.
  2. Switch to Board layout (simpler for external audience).
  3. Configure view:
    • Group By: Product Area (Customer Portal, API Platform, Mobile App)
    • Show: Features only (hide internal epics)
    • Columns: Quarters (Q1 2025 - Q4 2025)
    • Filter: Customer-Facing = Yes (custom field marks external features)
  4. Apply additional filters:
    • Status = Committed (exclude speculative work)
    • Exclude internal-only features (infrastructure, tech debt)
  5. Result: 24 customer-facing features across 3 product areas.

Phase 2: Sanitize for external audience

  1. Review feature titles:
    • Change "Legacy Auth Migration" → "Enhanced Security Options"
    • Change "API v3 Deprecation" → "Modern API Platform Launch"
    • Change "Mobile Perf Optimization" → "Faster Mobile App Experience"
  2. Remove internal-only fields:
    • Hide estimates (internal planning detail)
    • Hide team assignments (internal resource allocation)
    • Hide dependencies (internal technical coordination)
  3. Add customer-benefit descriptions:
    • For each feature, ensure description explains customer value (not implementation details).

Phase 3: Add roadmap disclaimers and context

  1. Add roadmap title: "2025 Product Roadmap".
  2. Add description: 
    This roadmap shows features we're committed to delivering in 2025.
    Timelines are estimates and subject to change based on customer feedback and priorities.
    For questions, contact product@company.com
  3. Add footer: "Last updated: February 15, 2025".
  4. Remove "Create" button (stakeholders should not add features).
  5. Make roadmap read-only for external view.

Phase 4: Publish and distribute

  1. Click Publish.
  2. Generate public URL: https://agility.digital.ai/shared/roadmap/abc123xyz.
  3. Configure publish settings:
    • Enable public access (no login required)
    • Disable editing (read-only for stakeholders)
    • Auto-refresh: Daily (keeps stakeholders updated)
    • Expiration: None (permanent public link)
  4. Distribute URL:
    • Add to customer portal "Product Roadmap" page
    • Include in monthly customer newsletter
    • Share in customer success conversations
    • Post in community forum.

Phase 5: Maintain and update quarterly

  1. Set calendar reminder: Update roadmap at end of each quarter.
  2. Q1 update process (April 1):
    • Move completed Q1 features to "Delivered" status (creates historical record)
    • Adjust Q2-Q4 dates based on current progress
    • Add new features for Q1 2026 (rolling 12-month view)
    • Update "Last updated" footer
    • Published URL automatically reflects changes (no redistribution needed).

Outcome: 24 customer-facing features communicated clearly to customer base via published roadmap, 500+ customers access roadmap via public URL (analytics tracked), customer success team references roadmap in renewal conversations, reduced "When is feature X coming?" support tickets by 40%, automatic updates eliminate manual PowerPoint maintenance, internal and external roadmaps stay synchronized.

Scenario: Portfolio Manager needs to analyze past 6 months of delivery performance to inform future capacity planning and estimate accuracy for upcoming annual plan.

Approach:

Phase 1: Configure timeline for historical view

  1. Navigate to Portfolio → Roadmap.
  2. Switch to Timeline layout.
  3. Configure view:
    • Group By: Team (8 development teams)
    • Show: Features (completed work)
    • Timeline: July 2024 - December 2024 (past 6 months)
    • Filter: Status = Completed OR Done
    • Sort by: Actual End Date
  4. Enable "Show Estimates" (displays estimate points on feature bars).
  5. Result: 142 completed features across 8 teams displayed historically.

Phase 2: Analyze velocity trends

  1. Review month-by-month delivery by team:

    • Team A: July (45 pts), Aug (52 pts), Sept (48 pts), Oct (50 pts), Nov (38 pts), Dec (42 pts)
    • Average velocity: 46 points/month
    • Observation: November dip (holidays impacted capacity)

  2. Compare planned vs. actual dates:

    • Red vertical line shows current date (December 31)
    • Features extending past planned end dates show late delivery
    • Count late deliveries: 23 of 142 features (16% late)
    • Average delay: 1.5 weeks

  3. Identify high-performing and struggling teams:

    • Team D: 18 features completed, avg 3 days early (high performer).
    • Team F: 12 features completed, avg 2 weeks late (needs support).

Phase 3: Analyze feature size vs. delivery success

  1. Filter to large features (>20 estimate points):

    • 28 features >20 points
    • 12 delivered late (43% late rate)
    • Conclusion: Large features have 3x higher late rate than small features

  2. Filter to small features (≤8 estimate points):

    • 67 features ≤8 points
    • 8 delivered late (12% late rate)
    • Conclusion: Small features deliver more reliably

  3. Recommendation: Break down features to ≤13 points for better delivery predictability.

Phase 4: Compare historical actuals to current forward plan

  1. Expand timeline: July 2024 - June 2025 (6 months historical + 6 months forward).
  2. Overlay current plan (future features in lighter color).
  3. Compare future commitment to historical velocity:
    • Team A planned for 55 points/month in Q1 2025
    • Historical average: 46 points/month
    • Overcommitment: 20% above historical capacity
    • Recommendation: Reduce Q1 2025 plan by 3-4 features per team.

Phase 5: Export findings for annual planning

  1. Save view: "6-Month Historical Delivery Analysis".
  2. Export to PDF (2 pages):
    • Page 1: Timeline view showing all 142 completed features
    • Page 2: Statistical summary (added as annotation)
  3. Prepare annual planning recommendations:
    • Target velocity: 45 points/month per team (conservative based on 46 actual)
    • Feature sizing: ≤13 points (based on delivery success analysis)
    • Holiday planning: Reduce capacity 20% in November, December
    • Team F support: Assign mentor, reduce commitment by 30% in Q1.

Outcome: 6 months of historical delivery data analyzed across 8 teams, velocity trending identified 1 overcommitted team and 1 underperforming team, feature sizing guidance established (≤13 points optimal), annual planning recommendations grounded in actual historical performance data, executive team gained confidence in annual plan estimates based on data (not guesses).

Frequently Asked Questions​

Should I use Board or Timeline layout for stakeholder presentations?​

Choose layout based on your audience's needs and the information they require:

Use Board layout when:

Audience needs:

  • Simple, easy-to-read view of what's coming in each time period
  • Clear deliverable commitments by quarter or month
  • Minimal technical detail, focus on outcomes

Best for:

  • Executive presentations: CEO, board members, investors
  • Customer communications: Public roadmaps, customer success conversations
  • Marketing/sales: Positioning upcoming features for campaigns or sales pitches
  • Quarterly business reviews: High-level delivery commitments by quarter
  • Non-technical stakeholders: Anyone unfamiliar with Gantt-style timelines

Visual advantage:

  • Looks like a Kanban board (familiar metaphor)
  • Each column is a time period (week, month, quarter, year)
  • Features appear as cards in columns (clear deliverable per time period)
  • Easy to scan: "What's coming in Q2?" → Look at Q2 column

Example Board message: "In Q2, we're delivering these 6 major features across our 3 product lines."

Use Timeline layout when:

Audience needs:

  • Understanding work duration and scheduling over time
  • Analyzing capacity, workload distribution, or resource conflicts
  • Seeing dependencies and critical path
  • Historical delivery analysis or velocity trending

Best for:

  • PI Planning sessions: SAFe teams coordinating cross-ART dependencies
  • Product/portfolio managers: Detailed capacity and scheduling planning
  • Project managers: Tracking delivery dates, identifying schedule risks
  • Leadership who plans strategically: Analyzing workload trends, historical velocity
  • Technical planning sessions: Engineers coordinating complex dependency chains

Visual advantage:

  • Shows duration with bars spanning start-to-end dates
  • Continuous timeline (not discrete columns) shows overlapping work
  • Dependency lines visible between portfolio items
  • Color-coded status shows progress along timeline
  • Red vertical line indicates "today" (past vs. future clearly separated)

Example Timeline message: "This epic spans 14 weeks from March through May, with 3 dependencies that must complete first."

Recommendation by scenario:

ScenarioLayoutWhy
Quarterly executive updateBoardSimple, high-level, outcome-focused
Customer-facing roadmapBoardEasy to understand, clear commitments
PI Planning facilitationTimelineDependencies and duration critical
Capacity planning sessionTimelineNeed to see workload distribution
Sales pitchBoardFeatures organized by delivery quarter
Historical velocity analysisTimelineAnalyze actual delivery vs. planned dates
Monthly stakeholder newsletterBoardQuick scan of monthly deliverables
Cross-team dependency coordinationTimelineVisualize dependency chains and conflicts

Can I switch between layouts without losing configuration?

Yes:

  • Same roadmap, same data, two different visual representations
  • Filters, groupings, and portfolio items stay the same when you switch
  • Save separate views for Board and Timeline if you use both regularly
  • Example: Save "Executive QBR (Board)" and "Team Planning (Timeline)" views of same roadmap

How do I prevent the roadmap from showing too much detail to executives?​

Strategy: Filter and group to show only high-level strategic information.

Step 1: Show only epics, hide features and stories

  1. Configure view: Show = Epics only.
  2. This hides lower-level detail (features, stories).
  3. Executives see strategic initiatives (epics), not implementation tasks.

Step 2: Filter by business value threshold

  1. Apply filter: Business Value Points ≥ 500.
  2. Only high-value strategic initiatives appear.
  3. Removes low-value or internal-only work from executive view.

Step 3: Filter by strategic theme

  1. Apply filter: Strategic Theme = "Market Expansion" OR "Customer Retention".
  2. Only epics aligned to strategic themes appear.
  3. Executives see roadmap aligned to stated company strategy.

Step 4: Group by product line or portfolio

  1. Configure: Group By = Product Line.
  2. Executives see delivery organized by their strategic product investments.
  3. Makes it easy to answer: "What's coming for Mobile product?".

Step 5: Use quarterly or yearly columns (not weekly)

  1. For Board layout: Column By = Quarter (not Week or Month).
  2. Executives see long-term strategic view (Q1 2025 - Q4 2025).
  3. Avoid overwhelming with week-by-week detail.

Step 6: Hide estimate and technical fields

  1. Remove estimate displays (internal planning detail).
  2. Hide team assignments (tactical, not strategic).
  3. Focus descriptions on business outcomes, not technical implementation.

Step 7: Save executive-specific view

  1. Apply all filters and configurations above.
  2. Click Save View.
  3. Name: "Executive Strategic Roadmap Q1-Q4 2025".
  4. Make visible to: Executive Team only.
  5. Reuse this view for all executive presentations.

Example configuration for executive roadmap:

Layout: Board
Group By: Product Line
Show: Epics only
Columns: Quarters (Q1 2025 - Q4 2025)
Filters:
  - Business Value ≥ 500
  - Strategic Theme IN [Market Expansion, Platform Modernization, Customer Retention]
  - Status IN [Committed, In Progress]
Hidden fields: Estimates, Team Assignments, Dependencies
View name: "Executive Strategic Roadmap"

Result: Roadmap shows 12-18 high-value strategic epics across 3-4 product lines over 4 quarters, no tactical detail, clear strategic delivery narrative.

Contrast with team-level roadmap:

Layout: Timeline
Group By: Team
Show: Features (epics and features)
Timeline: Weeks (next 12 weeks)
Filters:
  - Target PI = PI-3
  - Status IN [Committed, In Progress]
Visible fields: Estimates, Dependencies, Team Assignments
View name: "PI-3 Team Delivery Plan"

Result: Roadmap shows 60-80 features across 5 teams over 12 weeks with full planning detail for execution-focused audience.

Why this matters:

  • Executives don't need (and don't want) feature-level or week-by-week detail
  • Too much detail obscures strategic narrative
  • Executives care about: What outcomes, for which products, in what time frame, aligned to what strategy
  • Save team-level detailed roadmaps for execution planning, executive-level simplified roadmaps for strategic communication

Can roadmaps show cross-project or cross-portfolio dependencies?​

Yes, roadmaps can visualize dependencies between portfolio items across projects and portfolios, making them useful for coordinating complex delivery scenarios.

How dependencies appear on roadmaps:

Timeline layout:

  • Dependency lines connect upstream (predecessor) to downstream (successor) portfolio items
  • Color-coded lines indicate dependency status:
    • Green: Dependency satisfied (upstream completes before downstream starts)
    • Yellow: At risk (tight timing, minimal buffer)
    • Red: Broken (upstream completes after downstream needs to start)
  • Lines span across swimlanes (different teams, ARTs, projects, portfolios)

Board layout:

  • Dependencies less visually prominent (cards in columns, harder to show lines between columns)
  • Dependency indicators show on portfolio item cards
  • Click card to see upstream and downstream dependency details

Enable dependency visualization:

  1. Navigate to Roadmap.
  2. Switch to Timeline layout (dependencies more visible).
  3. Enable "Show Dependencies" option.
  4. Configure view: Group By = Project OR Portfolio OR ART (shows cross-entity dependencies clearly).
  5. Dependency lines automatically draw between related portfolio items.

Cross-project dependency example:

Scenario: Mobile App project depends on API Platform project

Roadmap configuration:

  • Group By: Project
  • Show: Epics and Features
  • Timeline: Q1 2025 (12 weeks)
  • Enable: Show Dependencies

Visual result:

Project: API Platform
  Epic: "Authentication Platform" ◄─────────┐
    Feature: "OAuth 2.0" (Weeks 1-4)        │ GREEN (satisfied)
    Feature: "SSO Integration" (Weeks 5-8)   │
                                             │
Project: Mobile App                          │
  Epic: "User Profile Features" ◄────────────┘
    Feature: "Profile Login" (Weeks 9-12) ← depends on OAuth completing Week 4

Dependency line connects "OAuth 2.0" (API Platform, Week 4 end) → "Profile Login" (Mobile App, Week 9 start). Line color: Green (satisfied, 5-week buffer).

Cross-portfolio dependency example:

Scenario: Enterprise Portfolio depends on Platform Portfolio for shared infrastructure

Roadmap configuration:

  • Group By: Portfolio
  • Show: Epics
  • Timeline: 2025 (full year)

Visual result:

Portfolio: Platform
  Epic: "Container Orchestration" (Q1-Q2) ◄──────────┐
  Epic: "Service Mesh" (Q3)                          │
                                                      │ RED (broken)
Portfolio: Enterprise                                 │
  Epic: "SaaS Multi-Tenancy" (Q1-Q2) ◄────────────────┘

Dependency problem: "SaaS Multi-Tenancy" (Q1-Q2) depends on "Container Orchestration" (Q1-Q2). Line color: Red (broken, both epics run concurrently, dependency can't be satisfied).

Resolution:

  1. Drag "SaaS Multi-Tenancy" epic from Q1-Q2 → Q3-Q4.
  2. Dependency line turns green (now starts after dependency completes).

Cross-ART dependency (SAFe context):

Scenario: 5 Agile Release Trains (ARTs) coordinating PI-3 delivery

Roadmap configuration:

  • Group By: ART (custom field)
  • Show: Epics and Features
  • Timeline: PI-3 (10 weeks)
  • Enable: Show Dependencies

Visual result:

ART 1: Platform Services
  Epic: "API Gateway v2" (Weeks 1-5) ◄───────────────────────┐
                                                               │ YELLOW (at risk)
ART 2: Mobile Experience                                        │
  Epic: "Mobile App Redesign" (Weeks 6-10) ◄──────────────────┤
                                                               │
ART 3: Backend Services                                         │
  Epic: "Microservices Migration" (Weeks 1-7) ◄───────────────┘

3 ARTs coordinating: Mobile App depends on API Gateway AND Microservices Migration. Dependency status: Yellow (API Gateway completes Week 5, Mobile starts Week 6, only 1-week buffer).

Dependency management workflow on roadmap:

  1. Identify broken or at-risk dependencies (red/yellow lines).
  2. Adjust scheduling:
    • Drag upstream epic earlier (complete sooner)
    • Drag downstream epic later (start after dependency satisfied)
  3. Verify dependency status turns green.
  4. Communicate changes to affected teams (dependency shifts impact their plans).
  5. Save updated roadmap with resolved dependencies.

Limitations:

Cross-workspace dependencies:

  • Roadmaps only show dependencies within same VAR::PRODUCT_NAME instance
  • Cannot visualize dependencies to external systems (JIRA, Azure DevOps)

Dependency detail level:

  • Timeline shows dependency lines clearly
  • Board layout shows dependencies less prominently (requires clicking into cards)

Performance with many dependencies:

  • 100+ dependency lines can clutter timeline view
  • Filter to specific portfolios/projects to reduce visual complexity

Best practices:

  • Use Timeline layout for dependency planning (Board less effective for dependencies)
  • Group by organizational boundary (Project, Portfolio, ART) to see cross-boundary dependencies clearly
  • Color-code dependency severity: Green = good, Yellow = review, Red = must fix before execution
  • Review roadmap dependencies weekly during PI Planning or quarterly planning cycles
  • Export dependency roadmap to PDF for PI Planning events (display on large screen for team coordination)

What's the difference between publishing a roadmap and exporting to PDF?​

Both options share roadmap content externally, but they serve different purposes and have different capabilities:

Publishing a Roadmap (URL-based sharing):

How it works:

  1. Click Publish from roadmap view.
  2. System generates unique URL: https://agility.digital.ai/shared/roadmap/abc123xyz.
  3. Share URL with stakeholders.
  4. Stakeholders open URL in browser (no VAR::PRODUCT_NAME login required).

Key capabilities:

  • ✅ Live updates: Roadmap automatically reflects latest changes (stakeholders always see current plan)
  • ✅ Interactive: Stakeholders can click portfolio items to see descriptions (read-only, can't edit)
  • ✅ No redistribution needed: URL stays the same, content updates automatically
  • ✅ Analytics: Track who accessed roadmap and when (engagement metrics)
  • ✅ Long-term sharing: Permanent link (unless you unpublish or set expiration)
  • ✅ Device-friendly: Works on desktop, tablet, mobile browsers
  • ❌ Requires internet: Stakeholders must be online to access
  • ❌ No annotations: Stakeholders can't add notes or comments to published roadmap

Best for:

  • Customer-facing product roadmaps (external stakeholders need current view)
  • Team-accessible roadmaps (internal teams check roadmap frequently)
  • Long-term reference (quarterly or annual roadmaps that update continuously)
  • Situations where content changes often (published URL auto-updates)
  • Stakeholders who prefer web-based viewing (no file downloads)

Example use case: SaaS company publishes customer roadmap showing 2025 features. URL shared in customer portal. Roadmap auto-updates monthly as features complete or dates shift. 500 customers access roadmap via URL throughout year. No manual redistribution required.

Exporting to PDF (file-based sharing):

How it works:

  1. Click Export PDF from roadmap view.
  2. System generates PDF file of current roadmap state.
  3. Download PDF file (static snapshot).
  4. Attach PDF to emails, presentations, documents.

Key capabilities:

  • ✅ Offline access: Stakeholders can view without internet
  • ✅ Printable: Print large-format posters for war rooms or presentations
  • ✅ Annotatable: Stakeholders can add notes, highlights, comments to PDF
  • ✅ Email-friendly: Attach to emails for distribution
  • ✅ Presentation-ready: Insert into PowerPoint, Google Slides, Keynote decks
  • ✅ Archival: Preserve point-in-time snapshot (e.g., "Roadmap as of Feb 15, 2025")
  • ❌ Static: PDF doesn't update when roadmap changes (must re-export and redistribute)
  • ❌ Not interactive: Can't click portfolio items to see details or dependencies

Best for:

  • Executive presentations (insert roadmap into QBR slide deck)
  • Printed materials (conference posters, office displays, PI Planning war room walls)
  • Email distribution (attach to customer update emails)
  • Archival/audit purposes (preserve roadmap state at specific point in time)
  • Offline review (leadership reviewing roadmap on plane, no wifi)
  • Situations where content is stable (quarterly snapshot that won't change)

Example use case: Product VP presenting to board of directors. Exports roadmap to PDF, inserts into QBR presentation deck. Board reviews PDF during meeting. Printed 36"x24" poster displayed in executive conference room for ongoing reference.

Decision matrix:

NeedPublish (URL)Export (PDF)
Always show current plan✅ Auto-updates❌ Must re-export & redistribute
Offline access❌ Requires internet✅ Works offline
Insert into presentation❌ Can't embed✅ Insert as image/slide
Print physical poster❌ Browser print only✅ High-quality print
Long-term stakeholder access✅ Permanent URL❌ Must redistribute updates
Add annotations/comments❌ Read-only✅ Annotate PDF
Track stakeholder engagement✅ Analytics available❌ No tracking
Archive point-in-time snapshot⚠️ Roadmap keeps changing✅ Static snapshot

Can I use both?

Yes, common pattern:

  1. Publish roadmap for ongoing stakeholder access (e.g., customer portal, team reference).
  2. Export PDF for specific events (e.g., QBR presentation, PI Planning posters, monthly email updates).

Example workflow:

  • Maintain published URL for customers: https://agility.digital.ai/shared/roadmap/product-2025
  • Export PDF quarterly for board presentations and email distribution
  • Published URL always current, PDF archives quarterly snapshots

Access control differences:

Published roadmap:

  • Anyone with URL can access (no login required)
  • Can set expiration date (optional)
  • Can unpublish to revoke access
  • Cannot restrict specific viewers (anyone with URL can view)

PDF export:

  • You control distribution (who receives file)
  • Recipients can forward PDF to others (no access control after distribution)
  • No automatic revocation (once sent, recipient always has that version)

Security consideration: If roadmap contains sensitive information:

  • Published URL: Anyone who discovers/guesses URL can access (share carefully)
  • PDF: More controlled distribution, but can't revoke after sent

Roadmaps vs Roadmap Reports​

The Roadmaps feature is distinct from Roadmap reports. Roadmaps provide interactive views where you can customize, filter, and modify portfolio items directly. Roadmap reports generate static visualizations of portfolio item data.

Troubleshooting​

Why don't I see any portfolio items on my roadmap?​

Roadmaps display portfolio items with planned begin and end dates within your selected time range. If the roadmap is empty, verify: (1) portfolio items exist in your project, (2) items have planned dates set, (3) dates fall within the visible time range, (4) your filters aren't excluding all items. Expand the date range or clear filters to see if items appear. Check the Portfolio Tree to confirm portfolio items exist.

Why do Board and Timeline layouts show different information?​

Both layouts display the same portfolio items but organize them differently. Board layout groups items by time periods (weeks, months, quarters) in columns. Timeline layout shows items as duration bars across a continuous timeline. If an item appears in one layout but not the other, check the time range—Timeline may be zoomed to a period where the item isn't visible. Both layouts stay in sync with portfolio item data.

How do I show milestones on roadmaps?​

Milestones appear automatically on roadmaps in both Board and Timeline layouts. In Board layout, milestones display in dedicated milestone boxes under date range columns. In Timeline layout, milestones appear as markers on the timeline at their specified dates. If milestones don't appear, verify they're created and assigned to projects included in your roadmap scope and filters.

Why can't stakeholders access the roadmap even though I shared the URL?​

If you shared a regular roadmap URL (not a published roadmap), stakeholders need login credentials and appropriate permissions to view it. Regular roadmap URLs require authentication. To share with external stakeholders without system access, use the Publish feature to create a public URL that doesn't require login. Published roadmaps provide read-only access to anyone with the URL.