CA Agile Central Portfolio Manager Best Practices

When setting up and using CA Agile Central Portfolio Manager, we recommend the following best practices:

Structure your CA Agile Central project tree

There are two types of projects:

  • Strategy project
    • For product companies or Independent Software Vendors (ISVs), use a strategy project to represent a product or an area of a product.
    • For Information Technology (IT) organizations, use a strategy project to represent a multi-year program , a system, or a subsystem.
    • Create portfolio items in strategy projects.
  • Execution project
    • Use an execution project to represent a scrum team, a Kanban team, or a group of such teams.
    • Create user stories in execution projects.

This type of structure allows all levels of your organization to view and use CA Agile Central Portfolio Manager in a way that is useful to them.

For detailed information, see Set Up Your Project Hierarchy.

PI diagram

Given the definitions above, your CA Agile Central project tree should follow one of these two recommendations:

Add portfolio items to the correct projects

Portfolio items should be created in strategy projects.

A higher-level portfolio item (higher than the lowest portfolio item type) affecting multiple strategy areas should be defined in a strategy project encompassing all affected strategy areas, such as product family.

In deciding where to create portfolio items, be aware that the project hierarchy does not affect portfolio item rollups, such as % Done. The children of a portfolio item do not need to be stored in the same project nor a child project of the portfolio item itself. Rollups are calculated following the parent-child association between a portfolio item and its child stories (the lowest user story level if there are several levels of user stories below portfolio items).

If you use the Also show items from child projects option on the project picker when selecting a strategy project, you see portfolio items located in the selected project as well as those located in projects children of that selected project.

Portfolio items versus user stories

A portfolio item must represent market value to a non-development stakeholder . Someone from marketing, business, or management must understand the value delivered by a portfolio item to customers.

User stories are development requirements to implement the lowest-level portfolio items.

PI market value

Portfolio items can change projects when they go in execution

Portfolio items change projects only at the lowest-level portfolio item. In an Initiative → Feature portfolio hierarchy, a feature should be manually relocated from a strategy project to a execution project as the feature flows through the execution team. This is especially true when an execution team works on several strategies at a time.

Portfolio item types

A portfolio item type represents a grouping of market value.

Only the lowest level of portfolio item type flows through execution teams to be implemented in a series of user stories.

Portfolio item types at higher level provide a grouping of portfolio items of a lower level to make the information more readily understood to people outside of engineering. Conversely, portfolio items below a certain level provide a way to clearly state the increment of values to build to deliver the higher-level portfolio item. It acts as a function to define Done.

Each portfolio item type defines:

  • A level of granularity appropriate for its respective audience. The highest-level portfolio item type maps to the highest-level executives in your organization.
  • An order of magnitude for its duration to complete (the higher the magnitude, the longer the duration). For example, portfolio items at the lowest level should be small enough in effort to be delivered within a one to three month release .
  • A business process to go from idea to delivery.

All portfolio items of the same type should share the same level of granularity, duration, order of magnitude, and idea-to-deliver value stream.

Portfolio items versus projects

Create a project to represent either strategy (product, multi-year program, system) or execution. Create a strategy project to represent either a product, program, or system.

Create a portfolio item to describe the actual work (for example an initiative or feature) that will flow through execution.

Use this analogy to help you differentiate:

  • If you need to know whether something is started and how far along it is, create a portfolio item.
  • If you need to protect resource allocation, create an Investment Category value.
  • If you need to scope to something, create a CA Agile Central project for it.
  It is ok to create one of each for the same thing if you have more than one need.

Programs as a project or a portfolio item

Programs can be either. To track the program dates as well as progress status (% Done), a program (in the PMI definition: a collection of projects) should be represented as a portfolio item of type Program (with its projects as children portfolio item of type Project). Additionally, for the program manager to scope to just that one program, create a strategy project to represent the program.

Investment categories versus portfolio item types

The Investment Category field captures portfolio allocations, or budget buckets. The Portfolio Alignment custom app (ask your Technical Account Manager for code) allows you to monitor whether these strategy portfolio allocations are respected by the execution groups.

Permissions on projects

For PMO, program managers, and product managers:

  • Set editor permission on strategy projects (where portfolio items are created)
  • Set view permission on execution projects

For engineering:

  • Set editor permission on execution projects
  • Set view permission on strategy projects you want engineering to see

Note that once a level 1 portfolio item is accepted to flow through a team, you should relocate it to the execution project. The execution team can then add user stories to the portfolio item. This applies to any project tree structure.

Associate existing user stories to a portfolio item

Use any of these methods:

  • From the Portfolio Item detail page, select Page Tools → Bulk Choose User Stories.
  • From the User Story detail page, select Action → Convert to a Portfolio Item.
  • Portfolio Hierarchy app
  • Story Hierarchy app

Associate a portfolio item to multiple stories at once

Use the Bulk Choose User Stories and Bulk Choose Children options. Note that CA Agile Central plans to provide a way to filter by projects on the Bulk dialog.

Remove completed portfolio items from view

From any CA Agile Central tab :

  1. Select New Page and add the Custom Grid app.
  2. Set the Custom Grid panel settings to:
  • Object: Portfolio Item
  • Query: ((PortfolioItemType.Name = “Initiative”) AND (PercentDoneByStoryPlanEstimate < 1))

Roadmap plans: CA Agile Central plans to add more filters to some of the portfolio views (portfolio items, portfolio timeline , portfolio Kanban , portfolio hierarchy).

Define portfolio Kanban states

See Design a portfolio Kanban board in our Coaching Corner.

Multiple workspaces

CA Agile Central Portfolio Manager assumes that each workspace represents a single portfolio. If your workspaces each represent a product or a program and you want to track them as a portfolio, you need to migrate the data from these workspaces into a consolidated workspace. CA Agile Central provides professional services to perform the data migration. We also need to understand which scenarios may call for tracking multiple portfolios (each in its own workspace).

Please contact us at [email protected] with your input.

Planned start and end dates

The Planned Start Date and Planned End Date fields on portfolio items are intended for a product or program manager to communicate when a portfolio item will start and end. The dates are manually entered. They are not calculated or projected from engineering data. Setting these dates ensures the portfolio items are displayed on the portfolio timeline before engineering starts working on them, so early roadmap conversations can take place before engineering is impacted.


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.