PI Planning For Agile Execution and Lean Portfolio Management

Are you thinking about implementing PI Planning, also known as Program Increment Planning?

Those that have implemented it, they would tell you it is worth the effort! For those that have not, it is likely you have not found the best way to apply it to your situation just yet. This article will provide an understanding of PI Planning, show how it adds value and explain how to get started.

Table of Contents

1. Understanding PI Planning
2. Importance of Scaled Agile with Lean PPM
3. Benefits/Goals of PI Planning
4. Key Elements of PI Planning
5. PI Planning Event Details
6. Challenges and Pitfalls to Avoid
7. Best Practices
8. Summary

Understanding PI Planning

You may already be asking things like: Does this apply to my type of work, what is an increment, how often is this done or what do you mean by vision? If you are, keep reading!

PI Planning is Valuable No Matter the Methodology

Agilists have helped popularize this term in the last two decades, and for good reason. Scrum just wasn’t enough for planning work with multiple teams. When the Scrum movement started, the IT world celebrated the Agile Manifesto. Everyone loved the new ability to expand requirements through empirical knowledge and breakdown tasks ‘just in time’. (Don’t get me wrong, this is a great way to make progress on the work that is right in front of you!)

So why would Scrum teams need PI Planning? According to Meisterplan’s Head of Product Management, Stefan Schneider, Scrum alone was usually unable to coordinate multiple teams efficiently to meet goals. This often resulted in a sort of “empty space”, a “gap” between the high-level company goals (traditionally 1 per year) and what sprints could achieve every 2 weeks. PI Planning filled this empty space.

So how does PI Planning help under other methodologies? We know dedicated Scrum teams are not possible for every type of project. For other big initiatives, you are likely to see companies use a mix of methods to complete work or the employment of less dedicated teams.

While each delivery team is very capable of delivering effectively within their own area, it becomes a struggle when working with multiple teams or with teams who follow a different methodology. The planning of work between teams with mutual deliveries still needs a coordination layer to help with interdependencies, testing and release planning. As you likely know, if you are waiting on someone else, the whole project might get extended. Project Extension = Project Delays.

Trust me, keep reading and give this a chance. 😊

Importance of Scaled Agile with Lean PPM

We have published many articles about Lean PPM. For a quick reference to ground everyone, Lean PPM is focused on:

• creating value for the Portfolio,
• optimizing resource utilization (not overloading or underloading),
• managing risk from cross-project dependencies,
• providing results as quickly as possible,
• and avoiding waste.

Applying a Lean PPM framework will increase communication, productivity, quality and ultimately time-to-market.

Preview of How PI Planning Connects with Lean PPM

They say a picture is worth a thousand words. Well, how about the diagram below for starters!

This diagram shows where PI Planning fits into a Lean PPM process. Lean PPM starts with a strategy workshop before reviewing the project pipeline. In this example, PI Planning occurs every 6 weeks. Put another way, there are 8 periods, or increments, that force a conversation to happen. And before you ask: YES, this period of time is flexible and could be set for a different increment. 😊 

The cadence should provide enough “checkpoints” to quickly assess if the projects are still worth doing and if objectives will be met by doing them. Without this Lean PPM level, projects would continue to be worked on, and you’d find out too late that they’re not contributing to your objectives.

How to Prioritize and Assess Value of Work

Truthfully, this is a longer topic and varies substantially with the type of projects being done. Just for a teaser, I can list a few ways your product, projects and portfolio might currently be prioritized.

#1 – Voice 

Historically work was prioritized by a “Squeaky Wheel” (person who yells the loudest), a “HiPPo” (Highest-Paid Person makes the decision) or a “LIFO/FIFO” (Last request In is First Out/First request In is First Out).

None of these are recommended. (Did I need to state this? Probably not!)

#2 – ROI

Return on Investment (ROI) is traditionally used for large initiatives and is part of a formal business case. It is a very popular profitability metric and is often used to show how well an investment has performed.

In a nutshell, ROI is expressed as a percentage and is calculated by dividing an investment’s net profit by its initial cost or outlay. 

Pros:

• ROI can be used to make comparisons and rank investments in different projects or assets.

Cons:

• ROI indicators are lagging indicators.
• Based on predictable risk for homogenous systems.
• Difficult to quantify for strategic jobs.

#3 – Weighted Project Score

A weighted project score can be easily and flexibly applied to projects, providing a sense of direction while setting priorities. The score serves as guidance on which projects are more important than others and helps get away from the “trap” in #1. The scoring factors can be anything that makes sense for your type of work. Points are assigned to a project based on the answers given to some pre-set questions. The Project Score is a sum of all answers. An example:

• Strategic alignment: High gets 50 points, medium gets 25 points, low gets 0
• Payback period: 0-1 year gets 30 points; 2-4 years gets 15 points; and 5+ gets 9 points
• Risk of not doing: High risk gets 20 points; medium gets 10 points; low gets 0

#4 – CoD and WSJF

Cost of Delay (CoD) and Weighted Shortest Job First (WSJF) methods are similar to the weighted score example, they just have a very defined way to calculate the weighting. This approach was adapted from Don Reinerten’s book Principles of Product Development Flow. It has been used extensively in Agile development and is a quick way to balance priorities with effort.

WSJF and CoD are the simplest ways to compare features or Epics when deciding what should be done next.

The calculation is WSJF = CoD / Duration (or job size)

What is CoD? It represents the cost of delaying the implementation of that feature/idea, i.e. lost opportunity. 

Here are the factors in this equation:

• User-business value
  Relative value to the customer or business. 1 is lowest value to business, 20 is highest value.
• Time criticality
  Is there a specific deadline or cut-off point? 1 represents the lowest possible urgency and 20 the highest urgency.
• Risk reduction and Opportunity Enablement (RR&OE)
  This factor takes into account those fixes or upgrades to the system that might prevent a significant impact from materializing. Opportunity enablement considers what may be possible after implementation of the change. For example, the initial work may just create a ‘foundation’ on which future changes can be added more quickly. The range of 1-20 remains the same.
• Duration
  The exact duration is not part of the calculation (i.e. 5 /12 months) but rather how the work is compared to others relatively. Think of this as a T-shirt size, where 1 is XS and 20 is super-duper XL.

While you can assign anything from 1-20, it is more typical to assign a Fibonacci score (1, 2, 3, 5, 8, 13, 20) for each of the above factors.

Benefits/Goals of PI Planning

Meisterplan’s CEO Johannes Koppenhöfer believes PI Planning is the ONLY way management can get a high-level “roadmap you can trust”. Before PI Planning, no one could reliably commit to work weeks in advance; PI Planning gave everyone more confidence to provide a more predictable roadmap!

Meisterplan’s Head of Product Management, Stefan Schneider, argues a key benefit of PI Planning is its incremental approach to ensuring the company’s objectives can be achieved. PI Planning allows the company to steer things incrementally, adding agility to the traditional annual planning cycle. While executives routinely make incremental adjustments, PI Planning provides a framework which helps all else to follow.

Other benefits of PI Planning include:

• A more reliable roadmap delivery.
• Validated resource capacity and financial budgets for the prioritized objectives.
• Identification of portfolio risk in the next PI round by reviewing dependencies early.
• Alignment of all stakeholders through increased transparency of priorities. (Stakeholders are also referred to leadership, customers and team members.)
• Identification of preparation requirements for future PI rounds and clear ownership.
• Increase in team efficiency, estimation accuracy and resource optimization through continuous improvement.

Key Elements of PI Planning

PI Planning is about ensuring the ‘right work’ is progressing while managing capacity and dependencies between teams. PI Planning is worthwhile when these factors are considered: work complexity, number of resources and number of dependencies. [You can review the challenge section for more information on this point].

The Meisterplan team uses the following PI Planning workflow to keep track of the progress of each project. At each of these stages, a checkpoint is available to reject, pivot or approve further work.

PI Planning Meetings

The PI Planning is broken up to span multiple days with multiple meetings. 

PI Planning Event Focus

The main day (day 1) is team-intensive, and the goal is to get a lot done in a short time. The day looks first at the upcoming PI Period before shifting its focus to pre-requisites of future PI Periods.

Not everyone likes to get into nitty gritty details. If this describes you, do not read this section. 😊 The above section has already provided an overview of each of these events, so don’t say I didn’t warn you….

PI Planning Event Details

The terminology of PI Planning has a more Agile slant, which is why Agile terminology will be used below. Look at the pitfalls section to know some problems that may arise in a multi-methodology organization. The following section takes a look at the agenda of each PI Planning meeting, who should be there and what the ideal outcomes are. We hope this will provide a bit of structure to your own efforts!

PI Planning Retrospective: 1-Day before PI Planning

Purpose: Review & conduct a retrospective of the current Program Increment (PI) and consider improvements. Look for areas you can be more predictable, more efficient or faster.

PI Planning Part 1

All the approved High-Level Solutions from the previous PI Period should now be refined. By “refined” we mean that work should be broken down to bite-sized tasks, dependencies documented and each team estimate their tasks. This meeting reviews dependencies between teams and ensures the sequence of work would allow the PI Period goals to be met.

Purpose: Plan sequence of features/Epics for upcoming PI Period.

Example Of A Prioritized Project List With Dependencies

PI Planning Part 2

Part 2 assumes the High-Level Solutions have been analyzed and either approved or rejected. The approved High-Level Solutions are assigned owners in this second meeting. After PI Planning, the owner is responsible for getting the teams to refine the work into tasks and stories so they are ready to begin the next PI. (In Agile, refinement happens every Sprint.) The important point is the entire Epic should be refined and ready for development before PI Planning day.

Purpose: Select approved High-Level Solutions that that need to be refined.

PI Planning Part 3

Part 3 assumes a ‘gut check’ has already been done on the High-level Requirements, meaning the high-level cost/time still looks reasonable to complete. The completed High-Level Requirements then get assigned an owner during the meeting.

After PI Planning, the owner is responsible for scheduling time with other team members to analyze and design a High-Level Solution. The team considers alternative solutions that can be done with less time and lower risk if needed.

Purpose: High-Level Requirements that are ready for High-Level Solutions.

Meisterplan team tracks the following on their PI Progress Kanban board:

Review the preparation work that needs to be completed for future PI Periods. Below is an example how the Meisterplan team tracks their preparation steps.  

Actions After PI Planning

Challenges and Pitfalls to Avoid

Challenge

Not speaking the same language

When companies use multiple different methodologies across teams (i.e. some teams follow a waterfall framework while other teams are working Agile/Scrum), different teams end up speaking different “languages”. If these teams are in the same meeting or room, it is important to establish a common understanding of terms so confusion doesn’t result. To prevent this, we recommend that companies formulate a common “language” when they are meeting with other project teams. Incorporate this learning into team members’ onboarding.

Map of equivalent vocabulary across methodologies:

Challenge

Not knowing who should go to meetings 

Similarly to the challenge of not speaking the same language, it may not be clear who to invite to the meeting cadence. Consider the expertise, or “role”, that will facilitate swift decision-making. 

Each expertise group within the project should be in sync with key stakeholder groups outside of the core project team. These stakeholder groups are important for the project’s success and are likely not sitting in on project team meetings.

Challenge

PI Planning for multiple products/value streams.

Many companies provide different products or services. A common challenge is understanding when to incorporate PI Planning and when it does not make sense. 

When you have independently planned products or independently planned value streams, each should have their own PI Planning. This assumes that the product or value stream is above a certain level of complexity, number of resources/teams and number of dependencies. 

If there are several PI Plannings that take place:

• If there are teams shared between the products or value streams, like enabling teams, it is likely the ‘coordination role’ that will take part in multiple PI Planning events. The caveat is if the enabling team has a small part. Then the coordinator role from the program/product/value stream needs to be the coordinator outside the PI meeting.
• The Coordination Role from program level and/or team level, if not represented already, would join the Value Stream PI Event. In this case the Value Stream PI Event primarily focuses on progression of objectives/outcomes and ensures cross-program dependencies are reviewed.
• A Global PI Planning Event is recommended here. This is a global portfolio meeting where all products/value streams are considered together. This global portfolio meeting should focus on the transparency of progress in products/streams, plus a few important high-level strategy projects. It of course doesn’t need all team members, but rather the role(s) of coordination.

I have done my best here to show what this could look like:

Pitfall

PI Planning periods too close or too far apart

Typically, waterfall teams plan for two- to four-month milestones. Scrum teams usually commit only to two- to four-week planning cycles, and XP teams commit to two weeks or less. These differences create visibility and dependency challenges, as teams with differing methodologies struggle to make in-flight changes to work schedules as priorities change for other teams. To set the right PI Planning, think of your longest planning period. 

• If waterfall teams are involved, PI Planning could be 8-16 weeks.
• If only Scrum teams are involved, consider how long an Epic takes to complete on average. Are most Epics complete within 6 weeks? If not, set a PI Planning period every 12 weeks.

Keep planning separate from delivery cadence. Each team can continue working towards delivery per their own sprint schedule, but teams need to provide tentative work plans for upcoming PI Periods regardless.

Pitfall

Doing PI Planning without a retrospective to save time

Introducing PI Planning means change, and this always brings questions and often uncertainty. The people involved in the process can feel where sticking points might arise. The retrospective gives these concerns a platform and helps to discuss and address relevant issues. If this is left out, it becomes difficult over time to keep the sand out of the gears, even if the process has been set up optimally.

Pitfall

Too much time taken to prepare

Often with the waterfall mentality, a lot of time is given to the requirements before handing it off to the designers. Then the requirements are frozen which lays the path forward for everyone else. While it is important to know the sequence of features, there is a downside to getting into all the details and freezing the whole backlog. Consider instead how to prepare enough features/epics for the next PI, keep the descriptions light and leave it up to the teams to find and develop the tasks. The upside is evaluating new ideas/features when they arrive.

Pitfall

Planning work on a 12-month roadmap is difficult

Work estimation at a high-level is indeed difficult! It becomes even more difficult if Agile teams dig in their heels: “Why on earth do we need to estimate 6-12 months out? That is simply not Agile!” Hopefully this article has provided you a few useful tips to address this challenge, but the fact remains: simply checking of completed tasks is not portfolio planning. Build your own story why Portfolio Planning is critical to your business and help your teams understand its power. 

Here are some points we hear:

• Hiring good people takes time. You are usually challenged with “prove you need them”, or, if you are lucky, asked “when do you need them?” Capacity Planning is critical to analyzing long-term bottlenecks or key resource availability to determine if you have enough lead-time to make a decision to hire. And if budgets do not allow hiring to be done, the planning helps to see what cannot get done to set expectations. Good Portfolio Planning facilitates capacity views over a longer range, up to 12 months out, even when teams are Agile.
• Release or Go-Live planning affects the users and customers of what has been released. Have you ever been on a project that released ‘on-time’ only to find out no one is using what you released? Perhaps it is because 5 other teams also released something and the impact of all that change is too much for a user group, resulting in all projects failing to achieve their outcomes. Good Portfolio Planning is not only about releasing on-time but also managing the impact of change.
• Leadership goals and objectives can only be met when the ‘plan comes together’. Without planning for what comes ‘after’ the projects are completed, teams like marketing, sales, operations and/or support cannot contribute to getting the results the organization expects.

Best Practices

Scaling Agile in an organization:

When teams start using the Scrum framework, it is better practice to have all teams do Sprint Planning the same week. It is less important if the teams are on a 2- or 4-week sprint cycle. However, to align PI Planning, it is important that Sprint Planning can occur right after a PI Planning session.

While sprint planning is a very team-specific event, the coordination layer of PI Planning should be implemented for optimal synchronization across teams.

Milestones in a program / portfolio Epic

When creating milestones, base them on an objective evaluation of working systems. Milestones are a leading indicator of project success or failure and should track real progress. This is easier with Agile teams that force a working solution by end of sprint. Yet even with Waterfall teams, it is recommended to have milestones at least every 8 weeks. These milestones could still represent a working solution or at least a touchpoint to show off the concepts and designs faster. Agile doesn’t work if you have to wait for the release to be out in 6 months and only to find out it doesn’t solve any problems.

Roadmap communication

PI Planning is a way to have more confidence in a roadmap that you are willing to share. A better practice still is to have a common understanding with those you share it with. A couple questions usually come up, and it is important for stakeholders to have a common understanding:

• Is the start and end date a committed date or still planned? In other words, can one rely on the end date of the work? In Agile, PI Planning may only commit to the next PI Period while the rest is subject to change. Stakeholders should be reminded of this or there could be a misunderstanding if it is a commitment or just a plan.
• If work is shuffled, should I assume a project failure? It should not be seen as a project failure if work is postponed, cancelled, or pivoted. Rather, the process is working. Good leadership is comfortable saying ‘no’ or ‘not now’. Good leadership needs to be given enough facts for that decision. Without PI Planning’s checkpoints, most work is not subjected to the right level of scrutiny.

In Summary

Whew, you are almost done….

PI Planning is beneficial to any methodology. PI Planning forces an organization to introduce checkpoints, which allow you to ensure the right work is prioritized while optimizing resources and managing dependencies (be they team dependencies or work dependencies). The outcome is a more predictable roadmap that everyone has more confidence sharing.

Getting started takes process-oriented thinkers to keep improving the structure as well as influential leaders to keep the teams motivated. The best-case situation is to have someone you can consult with that has previous experience in PI Planning. Remember: crawl before you walk, and walk before you run!