Set Up Your Project Hierarchy

How you should set up your project hierarchy in CA Agile Central depends on your organizational needs. The hierarchy you’re trying to represent is your organizational structure. A project in CA Agile Central just means a node of your organizational structure.  

Setting up your project hierarchy includes:

Basic hierarchy

team nodes

CA Agile Central tracks the rate at which work flows through a team to determine a predictable and sustainable pace. In Agile, teams perform best when they are cross-functional and persistent.  

Multi-level hierarchy

cross functional teams 

If you later need to restructure your projects and work items, consider the following:

To get started in CA Agile Central, define the hierarchy for a logical division of your organization (R&D, Sales, Marketing)—not your whole structure. Start with a simple structure and allow it to evolve.

Best practices

Teams can be at different levels in the hierarchical structure. Use a parent node when you want to roll up across multiple teams or areas. The workspace will not automatically create a node at the top.

Do not duplicate teams in the hierarchy

duplicate

Recommendation: If the same teams own work from more than one backlog, there are four suggested methods to handle this. Whichever method you choose, you will still have tracking and visibility because you can specify charts at the level you want (stories, portfolio items).

 

Avoid using timeboxes as nodes

Timeboxes do not belong in the project hierarchy. To keep your timeboxes organized, CA Agile Central recommends using releases on the  Plan → Timeboxes page.

Do not put testing structure into the hierarchy

Do not add testing structure to the project hierarchy. For an introduction to test structures in CA Agile Central, see CA Agile Central Quality Management Overview. If you don’t have CA Agile Central Quality Manager, you can associate test cases with user stories and use a tag or test case field to track the functional area.

Remember to put a top node on the hierarchy

Remember to put a node at the top of the structure. The workspace will not automatically create a node at the top. You need to have it here so you can roll up data.

Advice from CA Agile Central coaches

Key factors of successful organizations include:

Persistent, cross-functional teams

CA Agile Central tracks the rate at which work flows through a team. This measurement will allow you to predict how much work a team can accomplish at a sustainable pace. One key to predictability is that the team must be persistent with the same people doing the work from week to week. In order to measure the rate at which the work is being completed, all of the necessary contributors must be counted as members of the team, such as developers and testers.

Aligned timeboxes

When multiple teams are using an iterative process like scrum, aligning timeboxes leads to many benefits. Iterations and releases with the same start and end dates will automatically roll up in CA Agile Central, providing combined views of the status for a timebox. The Team Status page displays capacity across teams, which is useful when you are transitioning to agile and still have a few people contributing to multiple teams. Finally, aligning iterations makes it easier to steer multiple teams. The discomfort and annoyance that comes from moving to an aligned iteration heartbeat only lasts a few days, but the benefits continue over time.

Avoid one person owning work from multiple backlogs or projects

Agile effectiveness comes in part from team-based commitments. When people work on multiple teams or projects, their effectiveness decreases. If you must have a person working on multiple teams, you need to plan for a reduced capacity. CA Agile Central recommends considering that person to be a 50% contributor to one project, and 50% to the second project. If someone is spread across three projects at once, it’s best to not count their contributions when doing capacity planning, as it is too hard to predict which project they will contribute their time to. Furthermore, studies have shown that when a person switches between multiple tasks, their effective rate of work decreases significantly.

Hierarchies and CA Agile Central Portfolio Manager (RPM)

Create a portfolio item or a project?

Create a portfolio item if these statements are true:

  • It has a life cycle (start and end dates)
  • You need to track whether it is started or completed and the percentage of work remaining

Create a portfolio item or a parent user story (epic)?

Create a portfolio item if the above two statements are true and the work is important from a strategic perspective. In large companies, certain job roles are concerned with strategy while others are concerned with execution. Knowing who cares about the work will help decide whether it should be a portfolio item or a user story.

A portfolio item is a strategic initiative that requires a business case and a clear value statement. An epic is usually an engineering resolution of the problem.

Sample hierarchies for RPM

Your CA Agile Central project hierarchy can include layers for strategy and execution. These layers are nodes in the organizational structure. The distinction between these two types of layers is conceptual, not part of the CA Agile Central user interface.

Strategy layers:
  • Contain portfolio items
  • Allow scoping to the right level for strategic job roles
  • Especially useful for organizing and planning work that is not yet in development
  • Provide visibility into the percent done of a portfolio item
Execution layers:
  • Contain user stories and defects
  • Allow a team’s rate and progress to be tracked

There are no firm rules about exactly how to set up your project hierarchy in CA Agile Central Portfolio Manager. Organizations that have been using CA Agile Central for a long time before adopting CA Agile Central Portfolio Manager may have a different structure than an organization that is new to CA Agile Central. The following examples illustrate different ways in which to set up your project hierarchy in CA Agile Central Portfolio Manager:

Organization type Teams dedicated to specific products or programs Teams work on any or several products or programs at a time
ISV/Product company
Corporate IT group
Product/IT Hybrid

Conceptually, the lowest-level portfolio items start in a strategy layer but move to an execution layer when that work is assigned to a team. CA Agile Central recommends you update the project field to reflect which team is handling the work. Do not duplicate a portfolio item so it can appear in both a strategy layer and an execution layer.

If epics are entered in one branch (strategy) and children in another (execution), tracking at the team level can be confusing. Track children from the epic story's detail page.

Feedback

Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.