The Scaled Agile Framework site has a statement presenting PI Planning. “SAFe® has no enchantment except PI Planning,” it says. In this blog, I desire to reveal some insight into the PI Planning function and maybe explain why it is so profoundly respected.
Most associations that embrace SAFe® don’t completely take on it. However, assuming there is one thing that all SAFe® executions share practically speaking, it is PI Planning. Things being what they are, PI Planning? What’s the significance here in PI Planning?
Remote PI Planning is another challenge in the new pandemic scenario.
Well – PI represents Program Increment. A Program Increment is a set timebox of 8 to 12 weeks (default being 10 weeks as exhorted by Scaled Agile Inc.) (default being 10 weeks as suggested by Scaled Agile Inc.). The 10 weeks’ time-box incorporates 5 Agile Sprints or Iterations with each covering fourteen days. In the PI System Demo, which happens toward the finish of the 10-week time frame, the consequences of the work finished during the PI are introduced to the partners. (It is useful to know here, that a PI is an augmentation of a total Program. A Program is when groups and different assets are applied to some major, proceeding with advancement mission. A Program comprises many Program Increments.
Since the PI has 5 cycles and various groups cooperating to accomplish a typical vision, these groups must meet and plan their activities for the whole PI. The gathering likewise assists the groups with understanding their interdependencies and dangers. This is called PI Planning. It is a two-day meeting for a ten-week PI.
Why do PI Planning?
A PI Planning meeting requires two key sources of info: the Program Vision and the Program Backlog. The Vision discloses to the whole group because and how the work done in the PI adds to the general Solution. The Program Backlog records the best ten highlights positioned by need, alongside a short portrayal of the business benefit.
The Product Manager claims the Program Backlog and is answerable for focusing on it dependent on market real factors and different elements. There are additionally Starter Stories for every one of the main 10 elements, which assist groups with getting everything rolling on their PI plans.
PI Gear up
Everyone on the Agile Release Train is expected to attend the PI Planning. Remote participation is required if some team members are out of town. The PI Planning meeting is split into two days of sessions.
The Release Train Engineer hosts the PI Planning meeting (RTE, also called the Scrum Master of the Agile Release Train). In the first PI Planning session, the RTE presents the Vision and Top 10 Features. Then each team goes into their breakout to estimate their velocity for the first two iterations, if not all five. The teams size the Features and Starter Stories. End-of-day meetings with Business Owners, System Architects, and other stakeholders help clarify and highlight understanding.
On the second day, the teams break out again to refine their backlogs. The Business Owners assign a Business Value score to each of the Team Objectives. The Business Value score ranges from 1 to 10. (10 for the highest Business Value, 1 for the lowest). A Business Value score can be shared between objectives.
Then each team member presents their plan to the group. The plan identifies risks, predicts dependencies, and lists agreed-upon objectives and their Business Value. After each team has finished presenting, an aggregated list of team objectives and program risks is compiled.
The team addresses each risk using the ROAM (Resolved, Owned, Accepted, Mitigated) method. Finally, each team is given a confidence score (between 1 and 5) based on their confidence in achieving the various goals. If a team scores less than 3, they must express their concerns to the entire group. The worry may add to the list of risks, necessitate re-planning, or be informative. The teams revise their plans as needed until they are confident.
PI Planning Outputs
- A list of Team Objectives with Business Value, where objectives are business summaries of what each team expects to deliver in the upcoming PI.
- There are also Stretch Objectives that each team can choose from if they finish their work and have some velocity left.
- The team goals are combined and refined to form the overall Program PI Business Value Goals. The Release Train Engineer does this after the PI Planning meeting, not during it.
- We also learn about each team’s velocity for Iteration 1 and 2, as well as the User stories with Size assigned to these iterations.
- The Program Dependency Board shows the Features/Stories, Dependencies, and Milestones of the PI Planning process. Architects and UX designers can help identify these dependencies.
- PI Planning also lists identified risks and how they have been addressed using the ROAM (Resolved, Owned, Accepted, Mitigated) method.
Roles in PI Planning
Below are the key roles and their functions during PI Planning.
- Business Owner – approves Team PI Objectives.
- 10 Most Wanted Features from Product Manager (prioritized)
- RTE – outlines the planning process and outcomes.
- To enable team breakouts and features to story decomposition.
- Agile Teams – for breaking down Features into User Stories, identifying/addressing risks, and giving the crucial confidence vote
- To help identify inter-team dependencies and risks.
Epilogue
The PI Planning meeting is fundamental in bringing the whole ART group together and acquiring a mutual perspective of the work to be finished.
On a more ordinary note, the groups can recognize interdependencies and plan to effectively address them. The groups feel liable for conveying the PI targets they set.
In this way, the PI Planning meeting is now planned for the 5th iteration of the PI, the Innovation and Planning Iteration. It fulfills the longing for a viewpoint that groups want however seldom acquire. It appointed work arranging and control to the groups liable for conveyance.
