{"id":24329,"date":"2026-10-06T14:05:18","date_gmt":"2026-10-06T08:35:18","guid":{"rendered":"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/?post_type=article&p=24329"},"modified":"2026-10-07T11:00:19","modified_gmt":"2026-10-07T05:30:19","slug":"how-to-run-pi-planning-in-nimblework","status":"publish","type":"article","link":"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/article\/how-to-run-pi-planning-in-nimblework\/","title":{"rendered":"How to Run PI Planning in NimbleWork"},"content":{"rendered":"
\n

Skip Ahead to:<\/p>\n

<\/div>\n\n\n\n\n\n\n
1<\/span>Overview<\/a><\/td>\n<\/tr>\n
2<\/span>Understanding PI Planning<\/a><\/td>\n<\/tr>\n
3<\/span>PI Planning vs. Release Planning vs. Sprint Planning<\/a><\/td>\n<\/tr>\n
4<\/span>How to Run PI Planning in NimbleWork<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Overview<\/h2>\n

PI Planning is how several teams agree what they will deliver together over the next increment, and how they surface the dependencies between them before the work starts.<\/p>\n

NimbleWork has no menu called PI Planning. You run it with a Program<\/strong> project and four screens, each of which already does part of the job.<\/p>\n

\n\n\n\n
\n
Program Project<\/div>\n
the container<\/div>\n<\/td>\n
\u203a<\/td>\n\n
Child Projects<\/div>\n
the contributing teams<\/div>\n<\/td>\n
\u203a<\/td>\n\n
Release Planning<\/div>\n
the increment<\/div>\n<\/td>\n
\u203a<\/td>\n\n
Sprint Planning<\/div>\n
the iterations<\/div>\n<\/td>\n
\u203a<\/td>\n\n
Release & Sprint Status<\/div>\n
the progress<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

This article explains what PI Planning is and when you need it, then shows which screen does what. Each screen has its own article for the detail.<\/p>\n

Understanding PI Planning<\/h2>\n

A Program Increment, or PI, is a fixed block of time in which a group of teams works towards a common set of objectives. It usually spans a quarter and contains several releases and sprints. PI Planning is the event at the start of that block where the teams plan it together.<\/p>\n

The idea comes from scaled agile practice, where a single product depends on more teams than one backlog can coordinate.<\/p>\n

The Problem It Solves<\/p>\n

Sprint planning assumes a team controls its own work. Once delivery depends on several teams, that assumption quietly breaks.<\/p>\n

Each team still plans well in isolation. What nobody plans is the space between them. Two teams schedule the same shared service in the same fortnight. A feature waits a month because the team it depends on had other commitments. Nobody can answer whether the quarter is achievable without opening every project and adding it up by hand.<\/p>\n

PI Planning closes that gap by moving the conversation up a level. Instead of each team planning privately and discovering the clashes later, they commit to a shared set of objectives in one room, with the dependencies on the table.<\/p>\n

\"The<\/a><\/div>\n

What You Get Out of It<\/p>\n