Release portfolio planning, also known as Enterprise Release Management (ERM), is an emerging framework embraced by larger enterprises for planning and managing software delivery for multiple independent products at a portfolio level. Requirements and deliverables for independent products are prioritized and vetted collectively to determine where resources are best allocated based on a shared strategy for the portfolio. The net result of the planning process is agreement on the set of features by product that are approved for inclusion as part of a time-boxed portfolio release.
Portfolio planning roles and responsibilities
Key roles involved in the portfolio planning process typically include the following:
- Portfolio Manager - ownership for strategy at the portfolio level and planning and prioritizing the content to be included in the release. The portfolio planning process may align program managers to review proposed features from the product teams by strategic initiatives such as safety, compliance, localization, etc.
- Product Manager - ownership for product level strategy, planning and submitting product release feature candidates for consideration as part of the portfolio planning process.
- PMO - responsible for project and process management components of the portfolio release from planning through execution and delivery.
- Portfolio Planning Team - cross-functional team consisting of the Portfolio Manager, PMO, Product Management executive leadership, and senior level product managers. Auxiliary members from marketing, sales, services, and support are often included as part of the extended team.
Creating the plan
The following outlines setup and process recommendations to serve as a general framework for release portfolio planning in Aha! Refinements may be necessary to account for unique considerations for your company.
Create your product hierarchy
Before any planning can begin, it is first necessary to define your product hierarchy which consists of products and product lines. Product lines represent product families or suites that share a common strategy and will be used to define the portfolio in which the planning process will be based. Products represent the individual products that are part of the portfolio and should be defined along the lines of how they are marketed. Once you have configured your products and products lines, you are ready to define strategy for the different levels of your hierarchy.
Define strategy for the portfolio and and products
The planning process begins with having a cohesive product strategy at the portfolio level used to guide the strategic direction for the individual products. Strategy has three key parts consisting of Foundation, Market, and Imperatives.
The Strategy tab allows you to capture your strategy at each level of the product hierarchy and establish roll-up relationships between goals and initiatives at the product and product line (portfolio) levels. Goals and initiatives represent your strategic imperatives and can also be linked to releases and features to help with prioritization to ensure you are building what matters most. Use the strategy time frame to filter goals and initiatives to display only those that are relevant based on the release timeline.
Establish standard templates and processes
It is important for the portfolio manager and PMO to establish consistency with templates and processes that will be followed by all involved in the planning process. This provides a level of fairness for the individual product teams and makes the planning process easier to manage. Common templates should be established for the following:
- Scorecards - all initiatives and features should be measured against the same criteria. More details on this follow.
- Status workflows - all releases and features should have the same status workflows. More details on this follow.
- Release phase and milestone templates - all product sub-releases that are part of the portfolio Master Release should be following a standard best-practice go-to-market release methodology.
- Feature and requirement templates - it is important that all the product managers document features (and requirements if applicable) in a similar manner to provide the desired context when they are being evaluated by the portfolio planning team.
The release name needs to be communicated to the product managers so they can all adhere to an agreed upon naming convention for their backlog of feature release candidates (e.g. Portfolio Release Name-Product Name-RC's).
Establish standardized scorecard(s) to be used for prioritization
Aha! Scorecards should be used to prioritize initiatives and features being considered for a portfolio release. Initiatives can be prioritized to help with identifying which strategic initiatives are most important in reaching the overall vision and goals established for the portfolio release. Features can be linked to initiatives and also need to be prioritized in order to narrow down the scope of which features for which products will have the most impact on the portfolio goals.
It will be incumbent on the portfolio product manager to establish standardized scorecards for both initiatives and features that will be applied to each product in the portfolio so that they are all prioritized against the same criteria. The scorecard metrics should align with the strategic goals of the release.
The portfolio product manager should choose whether they wish to have a shared scorecard with product managers for prioritizing individual features or to have separate scorecards. The reason for choosing two would be to maintain the integrity of the scores assigned by the different individuals with different roles and perspectives. The best approach for two would be for the product manager to use the built-in feature scorecard and the portfolio manager to create a custom field scorecard type.
Customize the feature status workflow
The feature status workflow should be customized to represent the desired statuses to be used by each of the products in the portfolio. One key addition is the inclusion of a new status "Approved for release" which will be used by the portfolio planning team to designate features selected for the portfolio release.
Product managers prepare feature release candidates
Product Managers for the individual products prepare their backlog of feature release candidates for the portfolio release. Each product manager should organize their feature backlog in a parking lot release in the Features -> Board using the agreed upon naming convention for easy recognition.
The product manager should do the following with their list of features:
- Adhere to the designated feature and requirements template when documenting the features.
- Work with their engineering counterpart to provide estimates for each feature to be used later for doing capacity planning for the portfolio release.
- Assign scores to help with their individual prioritization. They may also be used as part of the portfolio planning process as well.
- Have the features sorted in their order of prioritization with the most important features at the top.
- Have features linked to the appropriate initiatives and goals as the portfolio manager will have a keen eye on which features align with their strategic initiatives.
- Have links to other features with dependencies both within their product or across-products.
Create reports for reviewing and approving features for the portfolio release
Once all the product feature release candidates have been finalized by each of the product managers, the portfolio manager and portfolio planning team can start the vetting process. The best way to review all the release feature candidates is through either the Features ->List, Reports -> List or Reports -> Pivot views.
Starting with the list report, you can use either the Features -> List or Reports -> List views. You can create the identical content using either report type. However, the Features -> List has the advantage of being able to make bulk edits. The Reports -> List has the benefit of being able to easily toggle to a Pivot report view using the same data objects. Use both to take advantage of the benefits they each provide.
Key inputs and capabilities for the report include the following:
- Filters for product name and release name allowing you to select the parking lot release candidates for each of the products in the portfolio so that all features can be viewed as a collective.
- All relevant information required to help with prioritizing and finalizing which features will be approved for the portfolio release. This should include initiative names, features scores and any other information that will factor in to the decision making process.
- Use the Sort columns button for sorting the list of features by multiple columns and quickly organizing the features into a forced ranked order based on the prioritization criteria.
Features that are chosen to be included as part of the portfolio release will have their status updated to "Approved for release". Click on the Feature name or reference # to open the feature slider page and make the update.
With estimates provided for each feature, you can perform aggregate level capacity planning at the portfolio level using the Features -> Workflow view. This view will provide estimate totals for each feature that is added to the "Approved for release" status and can help identify where the scope cut-off line needs to be.
Create the portfolio master release and sub-releases
Once the set of features chosen for the portfolio release have been finalized, it is time to create the portfolio release and the individual product releases that it will be comprised of. This is commonly handled in Aha! through the creation of a Master Release for the portfolio and sub-releases for the products.
An Aha! Master Release is designed for managing a suite of related but independent products that release together on the same date. It is used to communicate the portfolio level strategy and manage the go-to-market delivery phases and milestones. Product level sub-releases are connected to the Master Release and contain all the feature content as well as can have their own project management phases and milestones. This approach allows product teams to work independently while providing the ability to create a visual roadmap that represents the combined delivery.
Parking lot categories used for submitting feature release candidates can be converted into releases by going into the Release slider page -> Actions and unchecking the parking lot check box. Features that were not approved for the release should be moved to another parking lot category for future consideration. This release can then be connected to the master release and functions as a sub-release.
Below is a visual roadmap of a master release in the Reports ->Features view representing the combined delivery.