What is PI Planning?

Program Increment Planning, also known as Product Increment Planning or PI Planning, is one of the key phases in the quarterly business review process for the portfolio board in large Agile organizations. The teams involved in a program, in this case, Squads, Domains, Platforms, and a range of other stakeholders, carve out a dedicated time to come together to coordinate and plan the work that needs to be done over the next quarter (or 8 - 12 weeks). This work helps to add value to a program incrementally. While there are industry standards or recommendations on what constitutes a PI in Scaled Agile Framework, PI for Solvay may be unique to suit Solvay's needs because the transformation is a mixture of Agile methodologies. 

• PI Planning deepens collaboration, delivery, reflection, and improvement by giving Squads, Domain(s) and Platform(s)s dedicated time to plan the Epics and Stories that will be needed to execute the vision and product strategy outlined in the Initiative(s) and Portfolio Epic briefs.
• The event itself should mostly be spent collaborating with other Squads, Domains and Platforms (including key stakeholders that may not fall into any of those categories) to understand, amend, and confirm already-identified so that Squads, Domain and Platforms can revise their priorities where necessary.
• This would typically happen in a 'big room' with breakout spaces. However, PI Planning events test-run in Solvay today can happen online via Google Meet Video Conference call (+ breakout rooms) and Miro collaborative tool.

Preparation

• PI Planning events are most effective when the majority of planning takes place in advance of the PI Planning sessions.
• An adequate amount of time should exist between the communication of the PI memo (info shared with the participants in advance) and the PI Planning event to allow all the Squads, Domain(s) and Platform(s) involved in a program to prepare as much as possible.

Although it's not currently feasible to block days for PI Planning at Solvay, it is typically a two-day event including:

• ~3.5 hours for planning a three month of incremental value delivery work period
• ~2.5 hours for the refinement of this plan, following peer and management review

In order to be successful, a high proportion of User Stories (~80%) should have been loosely outlined ahead of time, along with:

• Some prioritization
• High-level dependency planning
• High-level risk and issue analysis
• Mapping of Stories to Epics (and features if needed) should be understood where possible

Outcomes

To be a more effective, adaptable, and transparent unit of Squads, Domain(s) and Platforms for the next PI iteration by outlining priorities; capacity; risks; and dependencies.

The plan from PI Planning is aspirational:

• Most user stories don't require DoD, DoR, or acceptance criteria.
• Rough estimates will suffice.
• Priorities are subject to later refinement.

However:

• Sprint 1 should be in a state to enter sprint planning, including: Definition of Done, Definition of Ready, Acceptance Criteria, high-level estimates, planned against capacity
• Sprint 2 should be planned adequately to allow backlog refinement
• Sprints 3 and 4 should be of a state to be refined in sprint 2 backlog refinement

Timeline (Recommendation but may not be feasible for now)

Timeline (Most feasible @Solvay for now)

Product-level QBR/PI Memo Creation

The Product QBR/PI memo sets out the product vision, and the Epics that will realise the vision. This is authored by the Product Manager (or Program manager if it is a program) and Product Management Team in consultation with Platform Pool Lead(s) and other stakeholders.

PI Planning - The event

How it works

Attendees

Participants in QBR / PI Planning include all Squads, Product Management team, Architect, Platform(s), and other stakeholders

Sample agenda

See sample PI Planning / QBR event agenda

Epics creation

• Epics are also as used as Features in the DT agile ways of working to some extent. This, of course, is under review and may change - if there is a need to add Feature to the current Jira issue types. Please ask the Agile Pool for guidance if you need to work with Epics & Features. 
• Product/Program Managers and POs create and confirm the Epics that the Squad(s) should deliver within the coming period QBR/PI period, understanding the Initiative or Portfolio Epic(s) outlined in the QBR/PI Memo and what is needed to deliver these.
• Each Epic should be linked to a Portfolio Epic in Jira to show this parent/child relationship
• Product/Program Manager advise on Epic prioritisation, using the WSJF technique to assist if needed
• POs advise Squads on which Epics they should take as their cue to create the Stories needed to deliver their work

Story Creation

From the DT Operational Playbook (Final V1.5 - 31/05/22) pg.69:

Establishing capacity for work

For core Squad members, the simplest way to start is to find out what availability they have (and are able to foresee) in the sprints of the coming quarter. Do they have annual leave coming up? etc. 

Sizing  / Estimation of work*

Stories should be estimated in story points using the Fibonacci sequence of 1, 2, 3, 5 etc., and Epics maybe be estimated using the t-shirt sizing estimation technique (S, M, L, XL, XXL) but using Fibonacci is the guidiance and the minimum sizing for S (small Epic for example) is 21. There is currently a field for this in Jira, which is can use as a place holder for sizing your Epics until you work out the numbers you are comfortable with.

Here is a recommendation as a guide but sizing effort will vary from squad to squad and from product to product:

Priorisation of work

There is a ‘Priority’ field in Jira when adding stories and Epics, which allows the Squads and Product Managers to enter whether the story / Epic is Minor, Major, Critical, Blocker. Low, High etc.

The WSJF (Weighted Shortest Job First) approach can also be used to prioritise Epics (we're adding a simple calculation to Jira) but should be considered 'nice to have' because of the complexity that goes into this calculation and low level of adoption in Solvay at the moment.

Other considerations

Individuals who are shared resources across multiple Squads

According to the the ways of operation Solvay, especially with the Platforms, some roles are provided as shared services to Squads. As part of PI / QBR Planning, Squads should identify which of these resources they need access to, and have a conversation with the Pool Leads about their foreseeable availability over the sprints of the coming quarter. Some examples of these roles include Data Engineer; Architects; Services Owners; and Product Owners from the domains - in some cases.

Risks, assumptions, issues, and dependencies (RAID)

The Miro board used in collaboration during the planning sessions should have a RAID area for recording ideas that fall into these four themes:

Risks

Identifying risks to each Squad delivery (objective) targets for the quarter is a key part of PI / QBR. It is important to remember that a risk is an unexpected event that could impact meeting the set objects for better OR worse across themes such as people, processes, quality, and information. Risks are distinct from a challenge or problem that has already happened and is impacting delivery — these are obstacles.

Squads should discuss and agree mitigating actions for risks. Ideally these mitigating actions can be kicked off during the PI / QBR by Squads engaging in conversation. 

During PI / QBR, Squads and (Initiative Groups - meaning, if we have multiple initiatives during the planning session) should also:

• Test the validity of assumptions
• Agree a resolution plan for issues
• Discuss and agree mitigating actions for risks

Assumptions

Assumptions are conditions or events that are expected to occur, and therefore if they don’t then our plans for delivery might be impacted.

Issues

An issue is a problem that has already happened that is now impacting your ability to deliver what you need to. Issues identified during PI / QBR Planning are often declared to be obstacles once the first sprint of the quarter begins.

Dependencies

Something that is known and needs to happen so that the squads can complete an increment (a quarter), but cannot be achieved by the squad alone. 

There are two types of dependency (Squad - related, but may apply to Initiative Groups within a Product):

1. Internal — an internal dependency is when you’re dependent on another area within your equad (member), or they’re dependent on you. These could include data required, materials needed or a specialist skill.
2. External — an external dependency is outside of your squad. These could include a dependency on another Initiative / Product or even an external supplier or key stakeholder. Generally, these types of dependency are managed through the product management team/squad with the support of Scrum Master(s).

When left unmanaged, dependencies can disrupt work and negatively impact team happiness. They can also affect workflow, metrics and ultimately delivery of value to our customers.

Find out more about Dependencies and their management

Tools

Google Meet: Meeting rooms

As Solvay's chosen collaboration platform, Google Meet allows multiple seperate breakout rooms to be created for Squads. The URLs for these rooms should be circulated in advance of PI / QBR Planning so that team members know where to hold discussions.

Miro: The digital whiteboard

Alongside Google Meet, Miro is the chosen collaboration tool for PI / QBR Planning (if you can not meet in person). We typically use a single large board with all the Squads information in one place. Experiments using multiple boards highlighted concerns that something would get lost along the way and it would be difficult if everyone can not see what is going on.

Product Increment / Quarterly Business Review Planning for Initiatives or Products may attract a lot of people, before experiencing significant performance issues. Of necessity, editing roles are may be reserved for Scrum Masters and Product Owners only for a start - if the planning session attracts 100s of people in the future..

Checklists for successful PI Planning / QBR

See Checklist for running successful PI / QBR events