Get Started with Lean Portfolio Management

Portfolio Level OKRs: Measure Long-Term Objectives

By now, your organization has defined team and program level OKRs to coordinate work around strategic objectives, and is able to measure the collective progress towards achieving those goals. Defining portfolio level OKRs can help you create alignment from the enterprise level all the way down to the teams, as well as measure the success of longer-term objectives, as key results evolve as the work progresses. Portfolio level OKRs usually measure objectives which last a year or longer, but the definitions of Objectives and Key Results remain the same. Simply put, Objectives ask, “where do we want to go?” and Key Results ask, “how will we measure our efforts to get there”? 

Parent-child relationships between OKR levels can also be created to represent the connection between related key results and objectives at different levels. For example, teams may be working towards multiple objectives that contribute to a higher-level, more long-term objective at the portfolio or enterprise level.

In a product model, each product should establish a linked set of early indicators and funnel metrics that make sense for their aspect of the business. Some examples of leading indicators are: 

• The number of people who use a new or modified aspect of a system 
• The time they spend on a specific screen 
• The load that users place on the system as indicated by your monitoring systems 
• The number of support tickets (up or down) related to various aspects of the system that have changed 
• Comments on social media 

Lagging indicators usually measure something that has happened in the past. For this use case, the main lagging indicator is the benefits (such as savings or incremental sales) captured on the program financial plan. As the organization goes through the cyclical process of delivering epics through the underlying features and stories, these leading and lagging indicators will collect data. As the epic hypothesis statement is either proven or disproven based on that data, sound persevere/pivot decisions can be made when investments are re-analyzed during PI Planning.

Lean Product Planning and Funding: Organize Around Value

The first step in shifting to a product model is not only defining the products that are required to achieve your organization's strategic initiatives, but setting up a funding model that is organized around delivering value to your customers. Adding products as part of the product funding process takes place on the Strategy Portfolio View, as shown in the example below. Creating a new product will likely include the population of a small amount of (configuration-specific) description and categorization attributes as determined by the data and information needs of the organization. You can edit these descriptive and categorization attributes if needed.

After adding products, the next step is to document product objectives and benefits, as well as manage their financial budgets and targets. On the Financial Planning Detail screen, enter benefits and revenue targets into the Benefits or Revenue Targets accounts, adding lines as needed. Examples of benefits may be cost savings or incremental sales (these benefits also serve as lagging indicators). This data is typically entered in the currency format, by quarter.

Enter in the labor costs either as one lump sum within the labor account, or within lines under the labor account by release train, or other key attributes. This allows for the capture the labor costs of resources, often as a lump sum for the year summing the salaries of the resources in the agile release train (ART). This is not used as part of the product sequencing and prioritization, but is often captured and stored within financial planning. Enter in any CapEx or OpEx costs into the appropriate account, adding lines as needed.

Manage Capacity Targets: ARTs/Team of Teams

Setting the team of teams’ capacity targets at the product level allows organizations to capture critical information for analyzing and sequencing epics. On the Financial Planning Detail screen, capture capacity targets (units) at the Agile Release Train (ART) level. Enter capacity targets in the Units - Points (or similar) account, adding lines for each release train as needed. Then add velocity/capacity units (points) for each Agile Release Train row, per quarter. These points will make up the velocity/capacity for each agile release train team, and should be fairly static for established teams.

Portfolio Capacity Planning: Analyze and Prioritize Epics

During PI/quarterly planning, use epic financial and capacity information to prioritize the portfolio backlog and decide which epics to bring into the value stream. First, navigate to the Planning menu and update your Planning portfolio to include all epics that are ready for analysis and approval.

In the Investment and Capacity Planning view, create scenarios to model different decisions (such as capacity or funding tradeoffs) for the next PI Planning.

Within your new scenario, use the Rank, Analyze, and Shift pivot views to sequence epics into program increments, while taking their size, value, and team capacity constraints into consideration. When using these screens, it may be helpful to create a column set that includes WSJF or other important attributes, such as OKRs, benefits/revenue, cost, risk reduction, or regulatory information. Keep in mind that your focus should always be the value being delivered, not purely the capacity/velocity being consumed.

When you select a portfolio kanban board to connect the epic to Planview AgilePlace, the epic will automatically sync across to your portfolio kanban board, appearing in the default drop lane of the board you selected. Depending on your unique configuration, this sync process is also sometimes completed as part of a lifecycle. 

Portfolio Backlog Management: Sequence and Deliver Epics

Once epics have been analyzed, prioritized, and synced across to your portfolio kanban board in Planview AgilePlace, Agile Release Trains (ARTs) coordinate how they will deliver the work during Program Increment (PI) Planning. 

A large part of PI Planning involves team breakouts and cross-team meetings to determine which teams will complete certain features, and detailed planning around the specific work (stories) needed to complete those features. During their planning sessions, teams focus on these main outputs: 

• Scoping and prioritizing their backlog of work 
• Scheduling features into sprints 
• Breaking down features into story cards 

Cross-team planning sessions are used to surface program-level risks, map cross-team dependencies, and discuss the team's plan with leadership and other stakeholders. Planning sessions should always be centered around your program and/or team boards, and your program board design should ideally reflect this.  

Before PI planning ends, team members and stakeholders take a "confidence vote" on the plan. Any major issues or reservations about the plan are discussed at this time.

During the sprint, teams usually engage in some of the following agile "ceremonies" to facilitate the completion of their work:

• Standups: Short, usually daily meetings for tracking progress and surfacing any obstacles slowing team output. For Scrum teams, stand-ups usually center around the following questions:
  • What did you finish/work on yesterday?
  • What are you working on today?
  • Do you have any blocks?
• Demos: These meetings (usually at the close of a sprint) give all teams within the value stream the opportunity to share their work with other teams and get direct feedback from customers and stakeholders. Information derived from demos is critical since it helps teams understand pain points, feature requests, and issues that need to be fixed.
• Steering: Project governance meetings attended by a group of stakeholders and Product Owners. Steering meetings focus on discussing whether the ART is successfully delivering against the plan. It can include re-prioritization of deliverables, as well as discussing and mitigating risks.

             

  

             

• Retrospectives: Meetings where Agile teams will review or re-visit past outputs. Kanban teams bring results from the board, ready to discuss active ways those things can be improved. Scrum teams usually center these around three questions: What worked well? What didn’t? How can this be more effective in the future?

As stories and features are completed, the teams will move those cards from left to right across the team and program boards. As the underlying work is completed, the epics will also need to be moved from left to right across the portfolio board as well.