Note: Depending on your workspace type, this article may refer to Aha! record types differently than your team does.
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 workspaces at a portfolio level. Requirements and deliverables for independent workspaces 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 workspace that are approved for inclusion as part of a time-boxed portfolio release.
This article outlines Aha! setup and process recommendations to serve as a general framework for release portfolio planning. Refinements may be necessary to account for unique considerations for your company.
Click any of these links to skip ahead:
- Portfolio planning roles and responsibilities
- Create your workspace hierarchy
- Define strategy for the portfolio and workspaces
- Establish standard templates and processes
- Establish standardized scorecard(s) to be used for prioritization
- Customize the feature status workflow
- Prepare feature release candidates
- Create reports for reviewing and approving features for the portfolio release
- Capacity planning
- Create the portfolio roll-up release and sub-releases
- Share your portfolio releases and schedules
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 teams by strategic initiatives such as safety, compliance, localization, etc.
- Workspace Manager - ownership for workspace level strategy, planning and submitting workspace 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, Workspace Management executive leadership, and senior level workspace managers. Auxiliary members from marketing, sales, services, and support are often included as part of the extended team.
Create your workspace hierarchy
Before any planning can begin, it is first necessary to define your workspace hierarchy, which consists of workspaces and parent lines. Parent lines represent workspace families or suites that share a common strategy and will be used to define the portfolio in which the planning process will be based. Workspaces represent the individual workspaces that are part of the portfolio and should be defined along the lines of how they are marketed. Once you have configured your workspaces and workspaces lines, you are ready to define strategy for the different levels of your hierarchy.
Define strategy for the portfolio and workspaces
The planning process begins with having a cohesive workspace strategy at the portfolio level used to guide the strategic direction for the individual workspaces. 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 workspace hierarchy and establish roll-up relationships between goals and initiatives at the workspace and parent 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 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 workspace sub-releases that are part of the portfolio roll-up release should be following a standard best-practice go-to-market release methodology.
- Feature and requirement templates - it is important that all the workspace 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 workspace managers so they can all adhere to an agreed upon naming convention for their backlog of feature release candidates (e.g. Portfolio Release Name-Workspace 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 workspaces will have the most impact on the portfolio goals.
It will be incumbent on the portfolio workspace manager to establish standardized scorecards for both initiatives and features that will be applied to each workspace 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 workspace manager should choose whether they wish to have a shared scorecard with workspace 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 workspace 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 workspaces 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.
Prepare feature release candidates
Workspace Managers for the individual workspaces prepare their backlog of feature release candidates for the portfolio release. Each workspace 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 workspace 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 workspace or across-workspaces.
Create reports for reviewing and approving features for the portfolio release
Once all the workspace feature release candidates have been finalized by each of the workspace 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, Roadmaps > List or Roadmaps > Pivot views.
Starting with the list report, you can use either the Features > List or Roadmaps > 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 workspace name and release name allowing you to select the parking lot release candidates for each of the workspaces 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 by enabling the Features > Workflow view for your account. Use the gear icon to display estimates and work logged for features in each workflow status, or for each user.
Create the portfolio roll-up 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 workspace releases will comprise it. This is commonly handled in Aha! through the creation of a roll-up release for the portfolio and sub-releases for the workspaces.
An Aha! roll-up release is designed for managing a suite of related but independent workspaces 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. Workspace-level sub-releases are connected to the roll-up release with their own project management phases and milestones and details on the individual features that constitute each release. This approach allows teams to work independently while providing the ability to create a visual roadmap that represents the combined delivery.
Parking lots in Aha! are releases without release dates. If you are using a parking lot as a repository for submitted feature release candidates, you can convert it to an active release by clicking on the parking lot's name in Features > Board, then clicking the More options button in the parking lot's detail drawer, and unchecking the Parking lot checkbox.
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 roll-up release and functions as a sub-release.
Share your portfolio releases and schedules
You can easily share your portfolio releases and schedules with your stakeholders by selecting one of the export options under the Share menu on the top-right of the page.
- To fold your portfolio release or schedule into a presentation, select Add to presentation. In your presentation, you can select the update frequency.
- To invite people outside of your Aha! account to view your portfolio release or schedule, select Share as webpage.
- For a static version of your portfolio release or schedule, export it to PNG image or PDF document.