Define your portfolio
Q: The examples of initiatives seem to be at a very low level for a portfolio level item. Is there a reason they are at such a low level of detail?
A: You can track portfolio information with any number of portfolio item levels. Typically, an initiative has funding associated with it, and below that a set of features implement the initiative. Cost is tracked at the feature level and aggregate up to the initiative to compare budget versus actual.
Q: How is technical debt prioritized and tracked (especially things that are related to corporate initiatives and not related to the portfolio)?
A: It depends how much the executives care about the portion of the overall funding is spent addressing technical debt. If they care about this, then identifying work in support of technical debt is done by tracking a Technical Debt investment category so the amount of funding gets monitored, and funding is left for non-technical debt work.
Q: Can this tool be used for a portfolio with combination of Agile and waterfall projects?
A: Yes, if most of your projects are Agile and only a few are waterfall. In that case, the waterfall teams can use a Kanban view to track their work. If most of your projects are still waterfall, the CA Agile Central integration to Planview may be a better solution.
Q: What is the S prefix in CA Agile Central Portfolio Manager?
A: We use the S prefix in the demo to identify Strategies—the highest level of portfolio items. Below Strategy is Initiatives (I) → Features (F). This is just an example of how you can structure your portfolio taxonomy. CA Agile Central Portfolio Manager lets you decide the number of levels and what you name each one. Our Portfolio steering workshop is designed to help you identify the portfolio hierarchy best suited for your organization.
Q: Is the value score the only free-form entry or does RPM provide methods for calculating the value score from customizable sub-scores?
A: At this time, the value score and risk score are numbers that you can identify based on your own scoring method.
Q: How do you manage throughput in the Kanban view? Work in Progress? Capacity? Dev hours?
A: In CA Agile Central Portfolio Manager (RPM), you can set up a set of Kanban states for each type of portfolio item (for example, at both the feature level and at the initiative level). For each of these states, you can define WIP and policies. The Kanban board will indicate when you are going over WIP. WIP in this case is determined by number of cards (such as features) in the state.
Q: A client of mine requests a graph structure for the Portfolio. Why is the tree structures conceptually more correct?
A: In this case, the relationship is hierarchical depicting more of an accountability rather than a dependency relationship. We will be adding graphical views that show many-to-many relationships like those you have with dependencies.
Q: Where is Story Hierarchy (not related to features) in the product?
A: It is in the Story Hierarchy app. If you have CA Agile Central Portfolio Manager (a module of CA Agile Central) then you will see only stories that are not connected to portfolio items. In RPM, there is another app called the Portfolio Hierarchy app that shows portfolio items and all their children including stories and tasks.
Q: S= story, not US = user story?
A: It is Story in this example, but you can define the prefix for the ID to be whatever you want (S or US or something else).
Q: Where are the RPM stories not connected to portfolio in CA Agile Central found?
A: In the Story Hierarchy app. You can find it in the app catalog. It shows stories (and their children) not connected to a portfolio item. Alternatively, the Portfolio Hierarchy app shows portfolio items and all their children (down to the task level).
Q: Where do the dates come from in the Gantt style chart? Is it a roll-up from when the lowest-level stories are scheduled by teams (for example, the iteration)?
A: The planned start and end dates come are determined and set by the product manager. The actual start date is automatically determined from the date that the first associated story goes into progress. The actual end date is automatically determined from the accepted date for the last associated story to be accepted for the portfolio item.
Q: How does the value stream map translate or transition to CA Agile Central's Kanban page?
A: Think of the value stream as the feature or initiative itself, and the Kanban as a process definition for the business process, states, and stages that you apply to your feature or initiative to take it from idea to market.
Q: When and how do you use ranking versus value score?
A: Value scores can be determined by a number of factors, and more than one value stream could theoretically have the same value score. Ranking takes into account other factors in addition to value that determine when a team could pull work (for example, risk, difficulty, dependencies, size, and so on). You would use rank to order the priority in which work is pulled considering all these factors.
Q: Your kanban page looks like what I've heard referred to as a release plan parking lot, but yours is intended to be a portfolio level?
A: We have a board view for the planning process at the release or iteration level, and also one for the tracking process at the portfolio level (one that tracks the portfolio item through states in the business and development process).
Q: Does CA Agile Central Portfolio Manager have connections with Excel, TFS, and RTC?
A: We have the ability to import and export from CSV as well as direct Excel import. At this time, CA Agile Central Portfolio Manager only integrates with CA Agile Central for Agile teams.
Q: What if an organization is using an in-house tool for the waterfall model?
A: You have two options: start tracking the waterfall projects using a Team Kanban in CA Agile Central, or look into using our API to build a homegrown integration.
Q: Does your product plan from top-down or bottom-up?
A: Both! There is lightweight, top-down planning with (timeline, portfolio kanban, and so on). We are also working on a new road mapping feature. Then teams are able to plan releases (mid-range and iteration). Those plans provide feedback to how good the top-down plans were and whether we need to adjust.
Q: With a focus on near-term initiatives, what would you do with the full wishlist?
A: It is helpful to have an idea backlog. That helps everyone see that we aren't losing good ideas, but we're not yet committing to them either.
Q: Are you using epics to represent a higher grouping of features?
A: Yes, SAFe talks about epics above features. Not everyone prefers that nomenclature. At CA Agile Central, we use strategy → initiative → feature.
Q: Is allocation based on actual time spent or estimates for the features in that initiative?
A: There are two ways to allocate. The target is by percentage goals. The planned is by estimates.
Q: Where can I get more information on SAFe?
Q: How do you help accounting solve the capital software development issue? Financial controls demand specific time accounting for one project, not blended features, enhancements, and defects in one release.
A: CA Agile Central can help you with the processes and tools to support capitalization. You will need to have a conversation with your accounting or auditing group. Our experience is that you can capitalize in Agile organizations. Pat Reed has presented a lot of good information at Agile conferences on this topic. We recommend this article.
Q: How do you quantify the value-for-value score?
A: Every company will do this slightly differently: Dean Leffingwell's recommendation, puts a relative value score (using Fibonacci numbers) on user-customer value, strategic value, and risk-opportunity value. Then, add those up to get a value score. You can create custom fields in CA Agile Central for those elements.
Q: Do you define a feature-as-a-deployable-capability that is part of a project?
A: Every organization defines feature slightly differently. We tend to think of feature as a piece of useful functionality that a stakeholder or user would recognize as valuable. A project might indeed have a plan to deliver a set of features. That said, Agile recommends moving away from a project mindset, in which projects have set starts and ends and scope and where we tend to assign people to projects to a product or application mindset, in which we support continuous enhancement of a product or app by adding features and fixing defects and flow work through teams.
Q: If a unit of measurement in the portfolio is product investment, how do we conduct investment decisions if the scope of product is ongoing and changing?
A: We have a target investment, but as the scope changes and we get new estimates, we discover that we are spending 40% of our budget on that portfolio item or area. That should prompt a conversation or review. Do we cut scope? Do we change our targets? This enables us to manage change.
Q: Can an architecture be developed if Kanban is used to pull from the portfolio backlog?
A: Balance seeing both the big picture to guide good design, and doing just-in-time development. If you work to build an architecture that supports everything you plan to do, then you limit your ability to change direction. One goal of Agile is to reduce the cost of change. Building heavier, bigger solutions increases the cost of change. Pull one thing at a time, but know everything on the board and have open discussions about what is likely to happen and what is less sure.
Q: When I look at Portfolio Items, I don't see the Value Score or the Risk Score.
A: Look at Track→Portfolio Items. Value and Risk Score are standard fields.
Q: Does the value creation process correspond to the product design and manufacturing process?
A: Thinking in terms of value creation is a shift from a development-is-a-cost-center mentality. It also shifts to thinking about your company more holistically. We create value when we define, design, development, test, manufacture, and document. It is all part of value creation.