paint-brush
Program Increment Planning Event in Agile by@andrew-romanukha
339 reads
339 reads

Program Increment Planning Event in Agile

by Andrew RomanukhaOctober 5th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Program Increment Planning Event in Agile is an Agile approach to delivering results in a short time. PI planning brings together multiple agile teams for an event that’s like an exciting adventure in and of itself: meeting colleagues from distributed teams, working together in close proximity, as well as socializing and team building in an informal atmosphere. PI Planning generally takes place over the course of two days, starting with presentations explaining the business context and product and architecture visions to be executed in the upcoming PI. Remote PI planning is a real-life example of companies successfully organizing and conducting such events popping up now and again.

Company Mentioned

Mention Thumbnail
featured image - Program Increment Planning Event in Agile
Andrew Romanukha HackerNoon profile picture

Long-term strategic planning is a remnant of the past that can’t reflect the fast pace of the digital world we live in today. Companies that implement an Agile approach, shift to delivering results in a short time all the while remaining flexible enough to adjust to any changes as they come. This calls for a completely different attitude in planning with the focus on short term goals that spin out for no longer than a few weeks or even days. Moreover, Scaled Agile helps manage the growing complexity and scaling of businesses to any size and number of distributed teams introducing new methods and tools, one such being Program Increment planning or PI planning for short. 

PI Planning and Agile Release Train

PI planning brings together multiple agile teams for an event that’s like an exciting adventure in and of itself: meeting colleagues from distributed teams, working together in close proximity, as well as socializing and team building in an informal atmosphere. It’s a principle on which the Agile Release Train operates.

Each agile team of 5-11 individuals is a functional unit that is one of many to comprise the Agile Release Train (ART). The ART, alongside stakeholders, takes upon the responsibility of aligning all the teams involved in developing, delivering and supporting the product post-release. An ART is aimed at providing a continuous stream of value to the end-user. 

PI Planning in SAFe 

In Scaled Agile Framework (SAFe), it is typical to plan the realization of an entire project in program increments. This is where PI planning comes into play. A common practice is to bring all agile teams together for a PI planning event in the course of which the teams work with the program backlog, team members plan out their scope of work, determine dependencies and evaluate program risks. 

What is the Goal of the PI Planning Event? 

This being said, PI planning event achieves alignment and transparency across multiple teams and helps have them commit to a common mission. Distributed teams may be lacking business context and product vision, only ever looking at one level of the complex problem at a time. Bringing people together to one location, having them sit face-to-face and establish the connection of working on a common goal, helps every team member puzzle the pieces together and get the full picture. 

Risk mitigation is another big focus in planning for the next PI. This entails identifying and evaluating the risks that may arise in the execution of the plan. Program risks may hinder the teams in meeting their objectives. The teams address and discuss each risk, coming up with probable solutions right on the spot.

Resolving and mitigating these program risks forms a crucial part of the PI planning event. 

PI Planning: How It Happens

PI planning generally takes place over the course of two days, starting with presentations explaining the business context as well as product and architecture visions to be executed in the upcoming PI. Then the teams have breakout sessions where they work on planning out their work for the next program increment. After that, the teams present their final plan, define risks and have a confidence vote. At the end of the PI planning, the teams are expected to deliver two outputs which are PI objectives and the program board. 

Pros of PI Planning 

  • Aligning the vision of all the people involved in the process
  • High-level planning 
  • Fast and flexible 
  • All team members and stakeholders get a chance to meet face-to-face and interact in an informal atmosphere 

Cons of PI Planning 

  • Short-term planning
  • Costly to organize (travel expenses, renting event venue, billable time) 
  • Time-consuming, 
  • May result in overcomplicated planning 
  • Extra roles and meetings that may be hard to consolidate 

Remote PI Planning: Is it Feasible? 

A big part of PI planning events is to have people come to one location and join efforts in working on the plan for the next PI. That being said, under certain circumstances, there’s no way to bring close to a hundred people across multiple locations to one spot for a few days of productive planning and teambuilding. These can be travel restrictions, financial constraints, difficulties in coordinating large teams or the pandemic. In this case, remote PI planning is something worth giving a try. There are real-life examples of companies successfully organizing and conducting remote PI planning events popping up now and again. It takes some more dedication and organizational skills, strong technical support and finding the right tools but it’s something worth looking into as a possibility. 

Is PI Planning For You? 

PI planning is a typical part of SAFe, however, businesses that don’t work in the IT industry or don’t use the Agile methodology can also benefit from it. It all comes down to the specificity of the team and the project in question. Some indicators that you don’t need PI planning are: 

  • You work in small teams with not that many people
  • The project is simple and straightforward with a lot of historical data and detailed documentation meaning everyone knows what they’re supposed to be doing
  • The product is familiar with expected results

In short… Do not scale if you can avoid it.