The HX Pocket Guide to PI Planning
PI (Program Increment) Planning is an essential ceremony in SAFe (Scaled Agile Framework) where the business, stakeholders, and teams come together to align and plan for the upcoming 12 weeks. PI Planning typically lasts about 2 days - which seems like a generous amount of time, but truthfully it can be stressful waiting until that point to start coordinating and breaking down the work.
In the 1-2 sprints prior to PI Planning, it’s important to begin thinking about what is coming up for your team ahead of time. The actual days of PI Planning should be mostly used to confirm plans and have conversations with other teams to ensure risks and dependencies are managed. This is a step-by-step process guide for Product Owners (POs) and team leads on how to prepare and go into the session feeling prepared and ready to take on the work.
1. Aligning with the Product Roadmap
To prepare for an upcoming PI, start by reviewing the product roadmap to understand what is being prioritized and if design involvement is needed. If it’s unclear or more context is necessary prior to planning, set up an overview meeting with your Product Management team. Once you have a clear picture of the feature/work, assign each item High, Medium, or Low priority (see below). Final deliverables for high or even medium priority items should be planned for completion at least a month ahead of the development start date - this will require coordination with the PO of the respective team.
- High Priority: Deliverables need to be finalized within the upcoming PI.
- Medium Priority: Deliverables need to be finalized in the next ~2-3 PIs. There may be a need for discovery to understand the correct solution to build.
- Low Priority: Deliverables need to be finalized in the next ~3-4 PIs. These items may not even be prioritized yet OR are an area of opportunity identified by HX.
2. Identifying Strategic Work
Once the roadmap work has been identified, the next step is to identify necessary longer term/strategic work that can be brought into the PI. These can be, but are not limited to: areas of opportunity that have been found through doing heuristic evaluations, conducting research, and reviewing other avenues of user feedback. Often times, the work within this category will be low priority and capacity should be first filled by work that has been prioritized.
3. Adding Operational Efficiencies
These are items added in to create smoother processes and better alignment in our own team and across others. Some examples of that are creating/managing a design system, adding new components, documenting usage, and adding them to your repository. Others include setting up various design and research operations. Some programs have Innovation and Planning (I&P) sprints to accommodate this kind of work, but most do not. Sprinkling Operational Efficiencies throughout your PI can be a way to avoid design/tech debt and to make space for innovation activities. Any leftover capacity from steps 1 and 2 can go towards operational efficiencies unless there are design components that need to be prioritized as part of a release.
4. Setting Up the PI Planning Board
Most SAFe Agile trains are using Jira and other PI Planning tools such as Confluence to track and house work - which you will need to adhere to according to your individual project, but to make planning easier, use Figjam (or any other white-boarding tool) to easily add/edit/move around the tickets as stickies before anything gets locked in officially. On the board, there needs to be a backlog section - this is where all of the features/work from steps 1, 2, and 3 will go and the first iteration of tickets needed per feature/work item. There also needs to be a template for each sprint in the upcoming PI where the team will work together on the day of PI Planning to slate the order tickets. During board set up, take the time to ask the team to check if they have any PTO and add it to the tracker. Once the team has done that, add the capacity calculations to the sprints.
5. Breaking Down the Work
Now that the features/new work has been identified within the categories above, they will need to be broken down into actionable tickets. This can be done by thinking through what the steps are to complete the work. For example, if screen designs for development need to be delivered within the PI, tickets for sketching/wireframes, design components, visual designs, and a hand-off package/prototype need to be created. At this point, there may not be enough information yet to give solid story points, but an estimate helps understand the total effort needed to complete the work. The team can refine in the actual PI Planning session and even further per sprint planning. Additionally, be sure to review these high-level tickets with the team to ensure they feel comfortable and confident that the work can be achieved within the allotted tickets or if it needs to be broken down further. It’s preferable to do this prior to the PI Planning session in order to track down outstanding information if needed. It’s important that the HX team is autonomous in writing and owning their tickets in collaboration with the larger Agile Release Train (ART).
6. The Actual PI Planning Session
As mentioned before, the actual session days are best used to communicate and collaborate with other teams that may have dependencies or linked work. This time will also be used to tentatively slate tickets into the sprints according to priority and need-by’s. This is when to pull other teams in to help determine when to align certain tickets with development start times.
7. First Sprint Planning
Now that PI Planning is complete, the next day is when the first sprint begins. That morning, either in a stand-alone meeting or within team sync, each ticket will receive an assignee and confirm story points. From there, the PO will start the sprint in Jira.
Happy planning!
