Version: 24.3

Designing Your Project Hierarchy

This article explains how to define Project Hierarchy in Agility.

Like folders on you computer, projects (also called releases) are containers that allow you to organize sets of related work (e.g., releases, sprints, backlog items, etc.) that will be delivered over time. When designing your project hierarchy, it's important to consider your current needs and requirements for future growth.

Viewing Your Project Hierarchy

There are two ways to view your project hierarchical structure:

Click on the Project Navigator, and then click on the Project Tree tab. (Note that you cannot create new projects in the Project Tree.)
Click the hamburger menu > Admin > Projects.

Good to Know...

The "System (All Projects)" project is the default root or parent project and cannot be changed or deleted. You can begin building your project hierarchy by creating new child-projects underneath it.
Do not use "System (All Projects)" for tracking backlog or any other items. Use it only to hold sub-projects or you will severely limit your future flexibility to evolve your project tree.
You can extend your hierarchy by adding new levels (or child projects) below any existing levels.
You can add a new parent project to a child project.
You can move a project to a new parent project (or level in the tree).

To learn how to create, edit, delete, and manage projects, see Project Administration.

Hierarchy Structure Examples

Project Tree Hierarchy

Depending on your needs, below are a few hierarchical structures to consider.

Use a structure based on...	To...
Project Names	Structure the Project Tree based on the names of your actual projects.
Projects or Releases	- Mimic internal or external releases for a specific product. - Define releases as levels in the project hierarchy under the project to which they belong. Note that cross-project releases may be defined as a higher level node in the project hierarchy, above the projects that belong to the release.
Teams	- Manage teams that use a different iteration schedules - Grant team access to projects that use the same iteration schedule so they have equal access to all the team's work
Multiple Sprint or Iteration Schedules	Set different sprint or iteration schedules for different segments of a project hierarchy and allow, for example, a set of teams to start their sprints on different days. Each project is associated with a single sprint or iteration schedule, which can be unique to the project or shared across multiple projects.
Single Sprint or Iteration Schedule	Reuse the same sprint or iteration schedule when various project teams need to be coordinated so they all start and end their sprints or iterations on the same day. Organizations practicing SAFe ®, for example, would use the same sprint or iteration schedule to coordinate the schedules across the various teams within an Agile Release Train.
Sprint or Iteration-based reporting	Roll up sprint or iteration-based reporting (e.g., velocity, capacity, and sprint or iteration progress bars), which can only be rolled up across shared sprint or iteration schedules.
Organizational Structure	Create higher level layers that represent a company, department, or division.
Clients in a consulting organization	Group projects for a specific client under a common location in the hierarchy to allow easy access to overall client rollup numbers.
Region	Group projects by physical location to provide rollup numbers.
Programs	Sometimes, rollup reporting needs may exceed even the great amount of flexibility offered by the hierarchical project relationships. Programs answer those needs. A program is a group of projects that allows rollup reporting of specific segments across the project hierarchy. Programs are defined by Administrators and can be viewed by anyone with project access. Programs allow you to roll up and report on the plans and progress of specific sets of projects, release or teams represented anywhere within the project hierarchy. See Managing Programs for more information.