Portfolio Best Practices

When setting up and using portfolio items, we recommend the following best practices:

Structure Your 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.

Project tree diagram

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

A. When Teams are Dedicated to Specific Products or Programs

Arrange strategy and execution projects as shown below to identify teams that work on each product or program.

This model assumes that each team only works on one product and that all work done by a team is for only one product.

  • Org Name (ex: Company X)
    • Product1 (strategy)
      • Team Group 1 (execution)
        • Team 1 (execution)
        • Team 2 (execution)
    • Product2 (strategy)
      • Team Group 2 (execution)
        • Team 3 (execution)
        • Team 4 (execution)

B. When Teams Work on Any or Several Products or Programs at a Time

Clearly separate the strategy projects from the execution projects so that execution teams are not associated with any particular strategy area.

  • Org Name (ex: Company X)
    • Strategy Organization (Product Manager group)
      • Product Line 1 (strategy)
        • Product 1 (strategy)
        • Product 2 (strategy)
      • Product 3 (strategy)
      • Product 4 (strategy)
    • Execution Organization (Eng)
      • Team Group 1 (execution)
        • Team 1 (execution)
        • Team 2 (execution)
      • Team Group 2 (execution)
        • Team 3 (execution)
        • Team 4 (execution)

Add Portfolio Items to the Correct 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 or to the business.

User stories are the smallest unit of work to implement the lowest-level portfolio items.

PI Market Value diagram

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 define the increment of values to build to deliver the higher-level portfolio item. Lower level portfolio items tell the team what successful completion means.

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 of product leadership 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 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 allows you to monitor whether these strategy portfolio allocations are respected by the execution groups.

Permissions on Projects

Learn more about permissions .

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 lowest-level 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:

Associate a Portfolio Item to Multiple Stories at Once

See Bulk Choose User Stories and Portfolio Items. Note that CA Agile Central plans to provide a way to filter by projects on the Bulk dialog.

Remove Completed Portfolio Items From View

You can remove a completed portfolio item from view from any CA Agile Central tab .

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

Define Portfolio Kanban States

See Design a Portfolio Kanban Board in our Coaching Corner.

Multiple Workspaces

When working with portfolio items, CA Agile Central 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).

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.