Skip to main content

Programs

A program is a cross-hierarchical collection of projects used for filtering and reporting. Programs let you group projects that do not roll up within a single hierarchy.

Use cases for programs​

Programs can represent:

  • Suite releases that encompass updates for multiple products
  • Program increments across an Agile Release Train (SAFe®)
  • Reorganized project groups after organizational changes
  • Teams supporting multiple products
  • Any grouping not supported by your hierarchy structure

Filter project selection by program to plan, track, or report on these subsets.

How programs include child projects​

When a project in the program contains child projects, those child projects are automatically included. For example:

  • Application Suite
    • Product 1
      • Q1 Release
      • Q2 Release
    • Product 2
      • Q1 Release
    • Product 3
      • Q1 Release
      • Q2 Release

A program including Product 1 and Product 2 also includes:

  • Q1 Release and Q2 Release from Product 1
  • Q1 Release from Product 2

Access programs​

Programs display in the Project Tree and are visible to all users. Members can only see included projects they have permission to access. Programs do not increase user access within the system.

To access the Project Tree, click the Project Navigator button in the top left corner of the page. From there, select the programs you want to work with.

System (All Projects) planning level

The System (All Projects) planning level sits at the top level of the planning level tree and was automatically created during setup. Create all projects or child projects underneath it to retain flexibility for scaling the planning level tree. For more information, see Understanding System (All Projects).

Suite release example​

A program called "Q1 Suite Release" can encompass work for the upcoming release of three products in a suite. Use this program to view progress of all work in the Q1 Suite Release.

  • Application Suite
    • Product 1
      • Q1 Release
      • Q2 Release
    • Product 2
      • Q1 Release
    • Product 3
      • Q1 Release
      • Q2 Release

When you select Application Suite and filter by Q1 Suite Release program, the system includes only items scheduled in Q1 Release under each project. The Tree & Filters panel in the Project Navigator provides visual indication of which projects are included.

View program metrics​

View project, release, and sprint metrics to measure progress towards release.

Use Cases​

SAFe Program Lead Managing Program Increments​

A SAFe program lead manages a 12-week Program Increment (PI) spanning four agile release trains. They create a Program "PI 2024.2" and add eight projects representing different value streams: "Customer Portal", "Mobile Experience", "Payment Platform", "Data Services", "Infrastructure", "Security", "Analytics", and "Integration Services". Each project maintains its own team, backlog, and sprints, but the Program groups them for PI planning visibility. During PI planning, the lead uses Program-level filters to view cross-project dependencies, features scheduled to the PI, and capacity across all eight teams. The Program provides strategic visibility without disrupting individual team autonomy or project structures.

Release Manager Coordinating Suite Releases Across Products​

A release manager coordinates a major suite release across five product projects that typically operate independently. They create a Program "Enterprise Suite 5.0" and add the five projects: "CRM Core", "Analytics Engine", "Reporting Tools", "Admin Console", and "API Gateway". Each project has different development schedules, but they must release together for the suite. The Program allows the manager to filter views to show only work scheduled to the suite release across all five projects. They use Portfolio reports filtered by the Program to track suite-level progress, identify cross-project dependencies, and communicate delivery status to stakeholders. After the suite releases, they create "Enterprise Suite 5.1" as a new Program for the next coordinated release cycle.

Portfolio Manager Tracking Strategic Initiative Across Organization​

A portfolio manager tracks the "Cloud Migration" initiative spanning 12 projects across different business units. The projects exist in various places in the organizational hierarchy and have different governance structures. They create a Program "Cloud Migration Initiative" and add all 12 projects regardless of their hierarchical locations. Using Program filters on Portfolio Kanban and Roadmap views, they track epics and features contributing to cloud migration across the entire organization. The Program provides a unified view for executive reporting without reorganizing projects or changing reporting structures. Team members continue working within their existing projects, unaware of the cross-cutting Program grouping used for portfolio visibility.

Product Owner Regrouping Projects After Organizational Reorganization​

A product owner manages projects that reorganize quarterly based on changing priorities. Q1 focused on "Mobile First", grouping three mobile app projects. Q2 shifts to "Platform Modernization", requiring a different project grouping including backend services, APIs, and infrastructure. They create a Program "Q2 Platform Modernization" and add six projects spanning frontend, backend, and infrastructure teams. The Program provides a temporary organizational lens for Q2 planning without permanently restructuring the project hierarchy. Projects maintain their permanent relationships, teams, and permissions, but the Program allows tactical regrouping for this quarter's strategic focus. At Q3, they'll create a new Program reflecting next quarter's priorities.

Agility Administrator Explaining Programs to Confused Project Manager​

An administrator receives a question: "Why is my project in a Program I didn't create?" They explain that Programs are overlay groupings that don't affect project functionality, permissions, or hierarchy. When an administrator adds a project to a Program, team members don't see any difference in their day-to-day work. The project's place in the hierarchy remains unchanged, permissions stay the same, and teams continue working normally. Programs simply provide additional filtering dimensions for portfolio management and reporting. They reassure the project manager that being included in a Program doesn't change their project's autonomy, team assignments, or backlog management. Programs are purely for organizational visibility, not operational control.

Frequently Asked Questions​

What's the difference between Programs and Projects in Digital.ai Agility?​

Projects are the foundational organizational unit in Digital.ai Agility, establishing hierarchy, permissions, teams, and backlogs. Projects exist in a tree structure with parent-child relationships. Programs are cross-cutting groups that organize projects for filtering and reporting without affecting project structure or permissions. A project can belong to multiple Programs simultaneously, while it can have only one parent project in the hierarchy. Use Projects for permanent organizational structure and operational execution; use Programs for temporary strategic groupings like SAFe Program Increments, coordinated releases, or cross-organizational initiatives.

Do Programs affect project permissions or security?​

No, Programs do not affect permissions or security in any way. Adding a project to a Program does not grant new permissions, change existing permissions, or alter security settings. Team members continue to have the exact same access they had before the Program was created. Programs are purely organizational filters for views and reports. If a user lacks permission to view a project, adding that project to a Program doesn't grant them access. Programs provide grouping for users who already have appropriate project permissions, but they don't create or modify those permissions.

Can a project belong to multiple Programs at once?​

Yes, projects can belong to multiple Programs simultaneously. This flexibility allows different stakeholders to organize the same projects in multiple ways. For example, the "Mobile App" project might be in both "Q2 Platform Modernization" Program (tactical quarterly grouping) and "Customer Experience Initiative" Program (strategic long-term grouping). Each Program provides a different organizational lens for viewing the same projects. This multi-Program membership is a key distinction from hierarchical project relationships where each project has exactly one parent.

When a project is added to a Program, are its child projects included automatically?​

Yes, when you add a project to a Program, all child projects in the hierarchy automatically become part of that Program. This cascading inclusion ensures complete visibility across project families. For example, adding "Enterprise Platform" project to a Program automatically includes "API Services", "Data Layer", and "UI Framework" if those are child projects. This behavior aligns with typical organizational thinking: if a parent project participates in an initiative, so do its components. You don't need to manually add each child project individually.

How should I use Programs in a SAFe implementation?​

In SAFe, use Programs to represent Agile Release Trains (ARTs) and Program Increments (PIs). Create a Program for each PI cycle (e.g., "PI 2024.1", "PI 2024.2") and add all projects participating in that PI. Use Program-level filters during PI planning to view features, dependencies, and capacity across all teams in the ART. Programs align well with SAFe's concept of aligning multiple agile teams to a common cadence and shared objectives. Create new Programs for each PI, allowing you to track historical PIs while planning future ones. Some organizations maintain persistent Programs for ARTs and create child Programs for individual PIs.

What happens to a Program when the grouped work completes?​

Programs remain in the system after their associated work completes, providing historical record of that organizational grouping. For example, after "Enterprise Suite 5.0" releases, the Program continues to exist with all its completed work visible. This history supports retrospectives, reporting, and understanding what projects contributed to past initiatives. If you prefer to hide completed Programs from active views, use filtering to show only current Programs. Some organizations maintain Programs indefinitely for historical reference; others archive or delete completed Programs after extracting necessary reports. Choose an approach based on your organizational needs for historical data.

Should I reorganize my project hierarchy or create a Program?​

Reorganize the project hierarchy when changes are permanent and affect day-to-day operations, team assignments, or permission boundaries. Project hierarchy changes are structural and impact how teams work. Create a Program when you need temporary or alternative grouping for strategic visibility, reporting, or planning without disrupting existing operations. Programs are lightweight overlays ideal for cross-cutting initiatives, time-boxed efforts like SAFe PIs, or multiple organizational views of the same projects. If you're unsure, start with a Program since it's non-disruptive. You can always reorganize the project hierarchy later if the Program grouping proves to be a permanent need.

Can I filter reports and views by Program?​

Yes, most Digital.ai Agility views and reports include Program filtering. Portfolio Kanban, Portfolio Tree, Roadmap, Release Planning Board, and various reports all support Program filters. Select a Program from the filter menu to show only work from projects in that Program. This filtering provides strategic visibility across grouped projects without manually selecting each project individually. Program filtering is especially valuable for cross-project reporting during SAFe PI planning, coordinated releases, or strategic initiative tracking where you need aggregated views across multiple projects.

Tags:
Last updated on