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
, a system, or a subsystem.
- Create portfolio items in strategy projects.
- Execution project
- Use an execution project to represent a scrum team, a
team, or a group of such teams.
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.
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
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
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
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
. 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.
Portfolio items can change projects when they go in execution
Portfolio items change projects only at the lowest-level portfolio item. In an Initiative →
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
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
- A business process to go from
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
- If you need to
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
captures portfolio allocations, or budget buckets. The Portfolio Alignment
(ask your Technical Account Manager for code) allows you to monitor whether these strategy portfolio allocations are respected by the execution groups.
For PMO, program managers, and product managers:
- Set editor permission on strategy projects (where portfolio items are created)
- Set view permission on execution projects
- 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:
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
- Select New Page and add the Custom Grid app.
- Set the Custom Grid panel settings to:
- Object: Portfolio Item
- Query: ((PortfolioItemType.Name = “Initiative”) AND (PercentDoneByStoryPlanEstimate < 1))
plans: CA Agile Central plans to add more filters to some of the portfolio views (portfolio items,
, portfolio hierarchy).
Define portfolio Kanban states
See Design a portfolio Kanban board in our Coaching Corner.
CA Agile Central Portfolio Manager assumes that each
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
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
before engineering starts working on them, so early roadmap conversations can take place before engineering is impacted.