Skip to main content
System StatusContact Support
VersionOne Community

Designing Your Project Hierarchy

This feature is available in Catalyst, Enterprise, and Ultimate editions.

editions-ceu.png

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.)

  • Select Admin > Projects, and then click on the + expand the project list.

Good to Know...

  • The "System (All Projects)" project is the default root/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

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/Releases

  • Mimic internal/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/Iteration Schedules

Set different sprint/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/iteration schedule, which can be unique to the project or shared across multiple projects.

Single Sprint/Iteration Schedule

Reuse the same sprint/iteration schedule when various project teams need to be coordinated so they all start and end their sprints/iterations on the same day.

Organizations practicing SAFe®, for example, would use the same sprint/iteration schedule to coordinate the schedules across the various teams within an Agile Release Train.

Sprint/Iteration-based reporting

Roll up sprint/iteration-based reporting (e.g., velocity, capacity, and sprint/iteration progress bars), which can only be rolled up across shared sprint/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.