Scaling Agile: The PI Planning


We have seen last article that PI Planning is one of the main SAFe event.
This is a periodic, large planning event before each Product Increment (PI) starts, when all teams plan their work and commit to a set of objectives to be delivered in the PI, both at team level and at program level. It’s a kind-of beefed-up version of a Sprint planning. 

What is the PI Planning?

The purpose of the PI planning is to gain alignment and commitment to a common mission, among all the Agile teams.

The input is a clear set of prioritised objectives: a list of Features detailing the vision, and the output is the Team and Program objectives for the Increment and its Program Board.

Cadence of a PI planning

When you are doing scaled incremental development (doing Trains as it’s called in SAFe), then having a periodic all teams planning event can be particularly useful. The key is visualising all of the team work streams together and creating a shared understanding (and view) towards the work. This is not particularly new: it is the good, old-fashioned release planning.

Cadence-based Product Increments plannings are the heartbeat of the SAFe.

The cadence is typically every 10 weeks (8 to 12 weeks range).
If you have two-weeks iterations, it means you will group five of them into a Program Increment.
Of course you can find your best arrangement. I worked in a program where iterations were 3-weeks long and a PI lasted 10 weeks: 1 week planning and reviewing plus 3 iterations. It worked well for that program’s specific needs and characteristics.

Logistics of the PI Planning

Everyone attends in person if possible but remote tools exist, useful especially in these times. Nowadays group video-conference tools are widespread, including teams’ breakout rooms that can be separately open.
Here are some tips and resource for holding a distributed PI planning.  

A PI planning is usually a 2-days event (can be stretched to 2.5 or 3 days if is online through different time zones) which may seem a long time but – as it’s said – a good preparation is half of the job done.
Here is a typical agenda with some indicative timing and drivers:

Agenda Day 1

  • Business Context (1h): state of the business and upcoming objectives [Executive]
  • Product/Solution Vision (1-2h): Vision and prioritised Features [Product Manager]
  • Architecture Vision and development practices (1h): Architecture, common frameworks, agile tooling, engineering practices, etc. [System Architect]
  • Planning context (1h): Facilitator explains planning process [Facilitator, as RTE]
  • Team breakouts (3h): Teams develop draft plans and clarify risks and impediments. Architects and Product Managers circulate and help.
  • Teams Synchronisation & Draft plan review (0.5-2h): Teams present draft plans, risks and impediments
  • Management review & problem solving (0.5-1h): Adjustments based on challenges, risks and impediments.

Agenda Day 2

  • Planning adjustments (1h): planning adjustments made based on previous day’s management meeting
  • Team breakouts (2h): Teams develop final plans and refine risks and impediments. Business Owners circulate and assign business value to team objectives
  • Teams synchronisation & Final plan, objectives (1-2h): Teams present final plans, risks and impediments
  • Program risks (1h): remaining program-level risks are discussed and “ROAMed”
  • PI confidence vote (15m): Team and program vote
  • Plan rework if necessary (1-2h): planning continues until commitment is achieved
  • Planning retrospective and moving forward (1-2h): retrospective, final instructions

Expect your first Pl Planning to feel a bit chaotic. Future Pl Planning meetings will become more routine.

Day 1: Draft Planning

Input: the prioritised features

PI Planning starts with a presentation of business context and vision by executives, followed by the Product Management team – who own all the business features – presenting the proposed list of Features wished to be completed in the Increment.

What are Features?

A Feature is a valuable product functionality: it describes a system behaviour that fulfil some user needs.

It is end-to-end and fits into the length of a PI, it’s therefore a rather small functionality; as usual for Agile the goal is to produce a working and complete artefact.

The Feature is expressed in plain language and is kept at high-level: a one-line title, a short description and includes expected benefits and the acceptance criteria. It’s what can fit into an Agile user story card.

The program backlog can also contain the so called Enabler Features; they are also features with the same attributes (a short slogan, benefits and acceptance criteria) but are used to build the development environments, the architecture or to explore prototypes or to facilitate specific compliance activities; everything not directly related to a business increment, they are usually created by the system architects or engineers.

The next step is that each team will break out and draft their own part of the PI plan, clarifying risks and impediments. Architects and Product Managers circulate and help.

Team breakouts

The team planning breakouts are where the teams create their Iteration plans and objectives for the upcoming PI.

As you can see in the next detailed steps, developing a team plan is an exercise very similar to the Sprint Planning but done for multiple iterations, all the ones composing the PI.

Step 1: Preparation

Usually each team has its own dedicated Area (the database, the User Management, a specific micro service, etc.) and will pick all the features belonging to that area.

Another preparation for each team is to enter their capacity for each Iteration.
Capacity is the portion of the team’s velocity that is actually available for any given iteration.
The capacity is calculated in the usual way: you have points for every Agile Team member contributing to the total team points and you multiply them for the available days in the Iteration.
You take in consideration the holidays, vacation and trainings, thus subtracting these days off.

The Team Velocity is also something to have prepared in advance. If it’s the first Planning, then is an assumption based on the capacity. Otherwise the team’s velocity for an iteration is equal to the sum of the points for all the completed stories that met their Definition of Done (DoD). As the team works together over time, their historical trend of average completed story points per iteration builds a reliable picture of the team’s velocity.

Of course, Capacity and Velocity must have the same unit.
They are not different from what we saw applied to one single Agile Team.

Step 2: Pick up a Feature and break it down.

The team will go Feature by Feature in order by Priority. Each Feature is broken down into User Stories by the Team, including estimating them.
The Product Manager will be available to help and clarify the Features.

Features will include the Enabler Stories. They are non-customer requests, but are stories that may be needed to implement later a Business Feature even if they don’t implement immediately a business  value.
May include any of the following: refactoring and spikes, building or improving infrastructure, verification of system qualities.

Step 3: Estimate the Stories using Story Points.

Estimation is done exactly in the same way as we have seen for the single Agile teams and – again – estimation is a whole-team exercise.
It increases accuracy by including all perspectives, it builds understanding and creates shared commitment.
Estimation performed by a manager, architect or a selected group negates these benefits. 

For the first PI Planning(s) until you have a reliable value,  you may use the iteration capacity and assuming e.g. that the smallest story (one point) is developed and tested in one day.

Step 4: Load the Stories into the Iterations

This step is about planning the estimated stories into the iterations composing the PI, in general following the priorities highlighted by Product Management.

One of the main points here is to find out the possible dependencies: is there a story that is a precondition for other stories? Enabler features which are needed before implementing some of the stories? Are there external dependencies (towards other teams or outside the program)?
Highlight all of the them you can find; it’s enough for now to simply link the dependencies between the stories. If it’s an external dependency can be something like “for this story we will need to have xyz from Team abc, before we can start.”

This is a similar exercise as done for a single Team but there are two differences:

  • usually in a large project there are many more dependencies with other teams
  • you don’t plan and consider dependencies for just the next single iteration but the Product Increment, which is more than one iterations.

Of course, it’s possible that not all the stories will fit into the iterations. It depends on the capacity and the velocity. The Team plans the stories based on their priority but also considerations such as having in place stories which are foundational and will be needed by others to build upon, independently on their priority.

Step 5: Write the Pl Objectives.

Objectives are business summaries of what each team intends to deliver in the upcoming Pl and they often map directly to the Features in the backlog, but not always.
The Objectives are clear statements and show how the team will align to the PI mission.

Examples of objectives:

  • Aggregation of a set of Features
  • A milestone like a trade show
  • An Enabler Feature supporting the implementation
  • A major refactoring

Step 6: Identify the uncommitted objectives.

Uncommitted objectives are used to identify work that can be variable and at risk within the scope of a PI.

Be careful as they are not extra things teams do ‘just in case there is time’ !
They are normally planned objectives but are very risky; if a team has low confidence in meeting a Pl Objective, it is encouraged to move it to uncommitted.
A typical uncommitted objective is an item that has many unknowns; would be better in this case to move it to uncommitted and put it in early spikes.

Uncommitted objectives are not included in the commitment, therefore making the commitment more reliable. Note that uncommitted objectives do count in velocity/capacity.
They just help improve and maintain the predictability of delivering business value.

Unfortunately uncommitted objectives are often seen as the way for stakeholders to load the teams with more work than they can do. So my suggestion is to use them sparingly.

Step 7: Identify any program risks and dependencies

This is the usual task to identify potential risks and mitigation actions for each one of them:  risks such as unexpected team members absences, infrastructure problems and so on.

Also, this is the time to lay down on the table all the dependencies.

Roles in the Team Breakouts

Agile Team: responsibility is to define the User Stories, plan them into the Iteration and work out interdependencies with other teams

Product Owners: have the content authority to make decisions at the User Story level

Scrum Masters: responsibility is to manage the timebox; identify as many risks and dependencies as possible for the management; review the dependencies, act as a request buffer for a team that has a lot of dependencies and in general facilitate the coordination with other teams for dependencies and ambiguities; eventually ensure the team has a draft plan to present and one which the team can commit to.

Draft plan review and problem-solving

This review happens at the end of the Teams Breakout and consists of two steps.

Step 1:
Each Team presents the summary of their first two Iterations and one or more draft Pl Objectives, including:

  • Capacity and load for each Iteration
  • Program risks and impediments

Step 2:
Management meets to make adjustments to scope and objectives based on the day’s planning.
Common questions during the management review:

  • What did we just learn?
  • Where do we need to adjust? Vision? Scope? Team assignments?
  • Where are the bottlenecks?
  • What features must be de-scoped?
  • What decisions must we make between now and tomorrow to address these issues?

Day 2 Finalise plans and establish business value 

Make planning adjustments

Based on the previous day’s management review and problem-solving meeting, adjustments are discussed.

Possible changes could be in the Business priorities (typically more high prio features are wished than the actual capacity), in the scope or vision.

Based on new knowledge (and a good night ‘s sleep), teams work to create their final plans.

Second Team breakouts

In the second team breakout, the Business Owners circulate among their teams and assign business value to identified Pl Objectives of one team’s draft plans from low (1) to high (10); they illustrate the larger purposes and thought processes around assigning business value and discuss them.

Here it’s important that the Scrum Master will act as facilitator between the Business Owners and the Team: it happens often – as the Business Owners are from the business side of the Enterprise – that they rank all objectives meant to reduce technical debt or build infrastructures as lower. Therefore upsetting the Team. It’s the Scrum Master task to solve these problems before they happen.

Teams finalise the Program Increment plan and also consolidate program risks, impediments and dependencies.  The program board is created.
Uncommitted objectives provide the capacity and guard band needed to increase cadence-based delivery reliability.

Final plan review

After all the adjustments, the final plans are peer-reviewed by all teams and Business Owners are asked whether they accept the plan.
If so, the team’s plan and program risk sheet are brought to the front of the room (or the virtual alternative).
If not, the plans stay in place, and the team continues planning after the review. 

Eventually all the plans are collected at the front of the room.

Addressing program risks

After all plans have been presented, the remaining program risks and impediments are discussed and categorised.

Here is one example of the process but every organisation has likely their own practices.
Someone, like the Program Manager, drives this. Each risk is read in front of all teams and stakeholders. It is asked if anyone can own, help mitigate or resolve the risks. Otherwise, it is accepted as it is.
Each risk therefore receives a “ROAM” category accordingly and is put  into a corresponding quadrant of the ROAM sheet for the program:

  • Resolved – Has been addressed. No longer a concern. 
  • Owned – Someone has taken responsibility.
  • Accepted – Nothing more can be done. If risk occurs, release may be compromised. 
  • Mitigated – Team has plan to adjust as necessary. 

Final plans and moving forward

PI Confidence vote: Team and program

This is a practice unique to SAFe as far as I know.
After dependencies are resolved and risks are addressed, a confidence vote is taken by the team and program.

The program Manager asks if everyone feels confident on the plan and all raise their hands showing one or more fingers: one finger = no confidence versus five fingers = very high confidence.
It’s important that everyone is honest in their confidence vote and raise any concern, as the commitment is binding. Again, it’s the Team Scrum Master responsibility to ensure their teams act on this.

If necessary (one or more teams / stakeholders have little confidence): planning is reworked and continues until commitment is achieved.
The commitment has two parts:

  1. Teams agree to do everything in their power to meet the agreed-to objectives
  2. In the event that fact patterns dictate that it is simply not achievable, teams agree to escalate immediately so that corrective action can be taken 

Things to pay attention are:

  • No pressure is put on any team to overcommit
  • Teams do not under commit due to fear of failure; it’s a fine balance and will take time to master it
  • The plan is not the goal, rather the alignment.
    The essence of the PI planning is to discuss among all teams and commit to a shared common list of achievable and believable objectives where everyone feels confident that dependencies have been – as much as possible – outlined and integrated. 

Eventually, all plans from the Teams are reviewed and committed and all their PI Objectives are synthesised into one Program PI Objectives list which is this PI final output and main takeaway.

Planning retrospective and moving forward (1-2h)

The Pl planning event will evolve over time. Ending with a retrospective will help continuously improve it.
This can be run as a normal retrospective (where the Scrum Master facilitates) but is specific only to the PI planning meeting dynamics and will be shorter, usually is done in one hour, max two hours.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s