Daniel Kunkel
Project Management Expert
Daniel is a dedicated team player with a clear focus on project management. He strongly believes the best results are achieved by small, agile and capable teams, whom he loves managing.

How not to mess up your Program Increment Planning

If you are a key decision maker in setting up or running a large-scale SAP implementation program or project, chances are that you thought about using SAFe Program Increment Planning for the delivery of your initiative. Before you do, consider that it will only reach the desired outcome if the leadership team has set it up for success.

This begs the question: What does it take to set up a delivery organisation for success? One of the most critical artifacts in SAFe is undoubtedly Program Increment Planning (also called PI Planning or Big Room Planning).

PI Planning is a SAFe artifact in which “teams create objectives they intend to accomplish in the upcoming Program Increment” (Source: https://www.scaledagileframework.com/pi-objectives).
Below we have compiled a list of the 4 most critical lessons learned from PI Planning for large-scale SAP Implementations:

1. Prioritise intermediate goals clearly and concisely

The main differentiator between SAFe organisations “by the book” and SAFe delivery organisations for SAP implementation is the fact that the latest has tightly intertwined goals that cannot be delivered independently – all functionalities must come together, be tested and be validated (especially in Pharma) before a Go-Live. Defining and prioritising these intermediate goals and making sure they are communicated to all teams in advance of the Agile Program Increment Planning event is crucial.

To facilitate these prioritisation activities, some of our clients have chosen to create feature bundles (“Releases” or “Epics”), which help increase template coverage to new business units/areas and represent a common goal all teams work towards.
During the PI Planning event, teams present their backlog based on the priority of the Release/Epic they assigned their individual features to. This way, it’s assured that all teams are always on the shortest path toward the most immediate and pressing goal.

An additional advantage of prioritising feature bundles beforehand is the fact that it creates a valuable checkpoint moment for goal alignment between stakeholders and the project’s leadership team. It also allows the teams to have a prompt tool to change direction if required.

2. Empowering Release/Epic Owners and creating clear mandate for scope management is critical

Any experienced project manager will tell you that one of the easiest ways for a project to overrun time or budget is improper scope management. An effect many of us know as “scope creep” is the slow – and sometimes almost invisible – increase over time in functionality associated with the same goal.

Keeping tabs on what is agreed upon (and really required) for a Go-Live is important during the Agile Program Increment Planning – and a task that is sometimes too far removed from very senior leaders. In our experience, managing the scope of Releases/Epics is best left to the people that know the required functionality best – the so-called Release/Epic Owners, who will safeguard the original scope and negotiate a roadmap for additional requirements to come in.

3. Learn from experience – insights from previous PIs are highly valuable

One of the key advantages of any Agile setup over other approaches is the quick succession of iterations that offers the opportunity to readjust ways of working based on previous results. While this applies to every phase and activity of a PI, it’s particularly true for the PI Planning activities, as mistakes during this stage are usually felt throughout the entire cycle.

There are two sources of learnings for PI Planning events – the experiences from the last PI Planning event itself and the outcomes of the PI.

The easiest way to capture feedback on the process is to ask the people involved in it – the moderation team, the Product Owner(s), the team members and all other stakeholder groups that might be present during the sessions.

The second source of input is the outcome of the previous PI, which is usually captured through reporting. It can address some topics regarding effort management, the accuracy of the Agile Program Increment Planning, progress assessment, etc.
While creating the reports required to answer these questions may not be straightforward, it can provide valuable input for future improvement.

4. Creating a toolchain will support the teams in the preparation and execution of PI Planning events

This is not very different from setting up any other planning activity based on a tool. Good project management practices like “capture data at source” and “minimise system breaks” should be followed. However, there are a few particularities towards a toolchain for PI Planning events:

  • Most of the tools used to capture the backlogs of large organisations offer the option to create hierarchies of items (e.g. “sub-tasks” making up “tasks” or “features” making up “epics”), which must be correctly captured and aggregated (lower/higher level) to avoid misleading results.
  • Depending on the size of the program/project, the amount of captured data could be substantial and difficult to migrate. Check restrictions on tools early on – especially cloud-based ones – and consider them in your initial choice of tool.
  • Ensure that the tool you chose has sufficient reporting capabilities, as this is crucial to manage your program efficiently.

The current landscape for tools to manage SAFe programs is relatively diverse – from Jira and Confluence to Smartsheet, the Google Suite or the MS Office package. It’s essential to know which ones serve your project’s purpose best.


Looking to have a more in-depth discussion about the importance of Agile Program Increment Planning events or any of the points mentioned above? Do not hesitate to get in touch!

Cookie Consent with Real Cookie Banner