PI Planning

In large companies, ten or more teams often work on the same product. Each team builds a piece of it, and these pieces later have to fit together. PI Planning is the meeting where all these teams align for the next roughly three months. They determine which tasks they want to complete in this time and at which points they need to wait on the work of other teams. The abbreviation PI stands for Program Increment, meaning the fixed time period, usually eight to twelve weeks, that is planned together. The meeting itself typically lasts two full days and takes place again every three months.

Why companies bring everyone to one table for two days

The most expensive mistake in large software projects is not bad code. It is discovering at the last moment that two teams have been working past each other. Team A built a feature that accesses an interface from Team B. Team B knew nothing about this and prioritized something else. Such gaps cost weeks when they only come to light shortly before delivery.

PI Planning brings this problem forward. Dependencies are voiced while they can still be resolved cheaply. Two developers clarify in five minutes in the room what would otherwise take three weeks over email. This is exactly why many companies consider the two days well spent, even though a hundred people aren’t coding during that time.

The second reason is less obvious. All teams hear the same explanation of why the company is pursuing certain goals. Without such meetings, many developers only know their own ticket, not the purpose behind it. Whoever knows the purpose makes better trade-offs in small everyday decisions.

How the two days unfold

The first day begins with presentations. Executives and product owners explain which goals matter for the coming months and what has changed in the market. Afterward, each team withdraws and plans on its own. It estimates how much work realistically fits into the coming weeks and writes down the planned tasks.

The central tool is a large wall or a digital board. Each team hangs its tasks in its own row, divided by individual weeks. Red threads or lines connect tasks that depend on one another. If a team has many red threads leading to another team, that’s a visible warning sign. In industry jargon, this wall is called the Program Board.

On the second day, the plans are adjusted until they fit together. At the end, each team member votes by show of hands on how confident they feel about the plan. This vote is called the Confidence Vote. Low scores are not a failure, but an indication that something is still too unclear or too ambitious. It’s important to note the difference from a classic project plan: the PI plan is a statement of intent, not a guarantee, and it is continuously adjusted over the three months.

SAFe, corporations, and the criticism of it

PI Planning comes from SAFe, the Scaled Agile Framework. This is a set of rules intended to transfer agile working methods from small teams to entire corporations. Banks, insurance companies, car manufacturers, and government agencies frequently work according to it. Anyone applying for an IT position at a large employer in Germany will often find SAFe and PI Planning listed directly in the job posting.

In business news, the term usually appears in connection with transformation programs. When a company announces it is making its IT agile, a SAFe rollout is often behind it. There is an entire consulting industry that accompanies such transitions and sells certifications for them.

There is plenty of criticism. Opponents call SAFe bureaucratic and say it disguises old-style corporate planning as a modern method. Two days of planning every three months, they argue, is a lot of effort for results that quickly become outdated. Proponents counter that large organizations simply cannot move forward in a coordinated way without a fixed alignment date. Both sides have valid points, and in practice the outcome depends heavily on whether the teams take the meeting seriously or merely go through the motions.