PI Planning

This is a BIG event and pays huge business benefits, including:

  • Establishing face-to-face communication across all team members and stakeholders
  • Building the social network the ART depends upon
  • Aligning development to business goals with the business context, Vision and Team & Program PI Objectives
  • Identifying dependencies and fostering cross-team and cross-ART collaboration
  • Providing the opportunity for 'just the right amount' of architecture and Lean User Experience (UX) guidance
  • Matching demand to capacity, eliminating excess WIP
  • Fast decision making



What you need to know before hand!


The Agile Release Train

  • Virtual organisation of 5 - 12 teams (50 - 125+ individuals) that plans, commits and executes together e*
  • PI (Program Increment) is a fixed timebox; default is 10 weeks
  • Synchronised iterations and PIs
  • Aligned to a common mission via a single Program Backlog
  • Operates under architectural and UX guidance
  • Frequently produces valuable and evaluable system-level Solutions



Value streams cut across organisational silos

  • Optimised for vertical communication
  • Friction across the silos
  • Location via function
  • Political boundaries between functions



Build cross-functional Agile Teams

  • Cross-functional, self organising entities that can define, build and test a feature or component
  • Optimised for communication and delivery of value
  • Deliver every two weeks



Agile Teams power the train

  • Coach the Agile team and facilitate team meetings
  • Removes impediments; protects the team from outside influence
  • Attends Scrum of Scrum meetings - mandatory! e*


  • Defines and accepts stories
  • Acts as the customer for developer questions
  • Works with product management to plan PIs


  • Create and refine user stories and acceptance criteria
  • Define / Build / Test / Deliver stories
  • Develop and commit to Team PI Objectives and iteration plans
  • Three to nine members



Cross-functional Agile Release Trains teams deliver value



Program roles govern the train


  • Release Train Engineer acts as the Chief Scrum Master for the train
  • Product Management owns, defines and prioritises the Program Backlog
  • System Architect / Engineering provides architectural guidance and technical enablement to the teams on the train
  • The System Team provides processes and tools to integrate and evaluate assets early and often
  • Business Owners are the key stakeholders on the Agile Release Train




Inputs and Outputs

  • Inputs:
    • Business context
    • Roadmap and Vision
    • Top 10 Features of the Program Backlog
  • Outputs
    • Committed PI Objectives
      • Set of SMART Objectives created by each team with Business Value assigned by Business Owners
    • Program Board
      • Highlighting new Feature delivery dates, feature dependencies among teams and with other ARTs, and relevant Milestones



  • Organisation readiness
    • Planning and scope context
    • Business alignment
    • Agile teams
  • Content readiness
    • Executive briefing
    • Product Vision briefing(s)
    • Architecture vision briefing
  • Facility readiness
    • Facility logistics
    • Facility/tech support
    • Communication channels



PI Planning Event

  • Cadence based PI Planning meetings are the pacemaker of the Agile enterprise

If you're not doing PI Planning, you're not doing SAFe!

  • Two days every 8 - 12 weeks (10 is typical)
  • Everyone attends in person
  • Product Management owns Feature priorities
  • Development teams own story planning and high level estimates
  • Architect/Engineering and UX work as intermediaries for governance, interfaces and dependencies




Estimate Stories with relative story points

  • A Story point is a singular number that represents:
    • Volume: How much is there?
    • Complexity: How hard is it?
    • Knowledge: What do we know?
    • Uncertainty: What's not know?
  • Story points are relative
    • They are not connected to any specific unit of measure
  • Compare with other stories
    • An 8 point story, should take 4 times longer than a 2 point story



Apply Estimating Poker for fast, relative estimating


  • Estimating Poker combines expert opinion, analogy and disaggregation for quick but reliable estimates
  • All team members must participate
  • Recommended to use Fibonacci series with a max of 8, due to small batching
  1. Each estimator gets a deck of cards
  1. Reads a job
  1. Estimators PRIVATELY select cards
  1. Cards are turned over
  1. Discuss differences
  1. Re-estimate
  • Estimation is a whole team exercise, that:
    • Increases accuracy by including all perspectives
    • Builds understanding
    • Creates shared commitment



Day 1 - Create & review draft PI plans

Why are we here?

  • Presented by the RTE:
    • Alignment to a common mission!
    • We are here to gain alignment and commitment around a clear set of prioritised objectives


Day 1 Agenda

08:00 - 09:00

Business Context


  • State of the business and upcoming objectives
09:00 - 10:30

Product/Solution Vision

(->Product Manager)

  • Vision and prioritised features
10:30 - 11:30

Architecture Vision and

development practices

(->System Architect)

  • Architecture, common frameworks, etc.
  • Agile tooling, engineering practices, etc.
11:30 - 13:00

Planning context

and lunch


  • Facilitator explains planning process
13:00 - 16:00

Team breakouts


  • Teams develop draft plans and identify risks and impediments
  • Architects and product Managers circulate
16:00 - 17:00 Draft plan review
  • Teams present draft plans, risks and impediments
17:00 - 18:00

Management review and

problem solving e*


end of day 1

  • Adjustments made based on challenges, risks and impediments


Planning Guidance

  • Expect the first PI Planning to feel a bit chaotic
    • Future PI Planning meetings will become more routine
  • Product Owners - Have the content authority to make decisions at the user story level
  • Scrum Masters - Have the responsibility to manage the timebox, dependencies and ambiguities


Features are implemented by Stories

  • Features are decomposed into Stories by the teams on the train
  • Small increments of value that can be developed in days and are relatively easy to estimate
  • Teams on the train collaborate to deliver features incrementally via user Stories
  • Features fit in one PI for one ART
    • Stories fit in one iteration for one team
  • Enabler Stories represent different types of work e*:
    • Exploration (prototyping)
    • Architecture
    • Infrastructure
    • Compliance


Align to a mission with PI Objectives

  • ~ 5 - 10 Objectives are business summaries of what each team intends to deliver in the upcoming PI
  • They often map directly to the features in the backlog (but not always) e.g.:
    • Aggregation of a set of features, stated in more concise terms
    • A milestone, like a trade show
    • An Enabler Feature needed to support the implementation
    • A major refactoring


Maintain predictability with stretch objectives

  • Stretch objectives do not count in velocity/capacity
  • They are planned and aren't extra things to do, just in case you have time
  • But, they are not included in the commitment, thereby making the commitment more reliable
  • If a team has low confidence in meeting a PI Objective, encourage them to move it to a stretch
  • If an item has many unknowns, consider moving it to stretch and put in early spikes


Starting fast with capacity based planning

  • Normalised estimation technique:
    • For every full time developer and tester on the team, give the team eight points (adjust for part timers)
    • Subject on pint for every team member vacation day and holiday
    • Find a small story that would take about half a day to develop and half a day to test and validate.
      • Call it 1
    • Estimate every other story relative to that one
    • Never look back (don't worry about recalibrating)


Setup your team area

  • Estimate capacity (velocity) for each iteration (sprint)
  • Identify PI Objectives
    • Identify Stretch Objectives
  • Identify Risks


Team Breakout

  • Identify and resolve ambiguities and manage dependencies
  • Negotiate with:
    • Product Owner
    • Other teams
    • Business Owners
  • Try to limit stories to 8 points
  • PI Objectives written in CLEAR business (as opposed to technical) language
  • Stretch Objectives identified
  • Program Risks identified


SoS - Scrum of Scrums

  • RTE conducts the SoS Sync
  • Participants include all SMs and others (where appropriate)
  • Sync Questions:
    • Has capacity (velocity) been identified for each iteration?
    • Have all stories been identified and story points estimated?
    • Have dependencies with other teams been identified and/or resolved?
    • Have trade-offs and conflicting priorities been discussed with Business Owners?
    • Have any program Risks been identified?
    • Read to start writing PI Objectives?
    • Anything required to be discussed with other other SMs (in the meet after)?
  • RTE holds a Meet After to discuss any issues


Draft plan review

  • Tightly timeboxed event
  • Defined:
    • Capacity (velocity)
    • Draft PI Objectives
    • Potential Risks
    • Dependencies
    • Impediments


Management Review & Problem Solving

  • End of Day 1
  • Management meet to make adjustments to scope and objectives based on the day's planning
  • Common questions:
    • What did we just learn?
    • Where do we need to adjust the Vision? Scope? Resources?
    • Where are the bottlenecks?
    • What features must be de-scoped?
    • What decisions must we take between now and tomorrow to address these issues?



Day 2 - Finalise plans and establish Business Value


Day 2 Agenda

08:00 - 09:00

Planning adjustments


  • Planning adjustments made on previous day's management planning
09:00 - 11:00

Team breakouts


  • Teams develop final plans and refine risks and impediments
  • Business Owners circulate and assign Business Value to team objectives
11:00 - 13:00

Final plan review

and lunch

  • Teams present final plans, risks and impediments
13:00 - 14:00 Program risks
  • Remaining program level risks are discussed and ROAMed*
14:00 - 14:15 PI confidence vote
  • Team and program confidence vote
14:15 - ???

Plan rework

(if necessary)


  • If necessary, planning continues until commitment is achieved



Planning retrospective and

moving forward

  • Retrospective
  • Moving Forward
  • Final Instructions

*ROAM: Resolved, Owned, Accepted, Mitigated



Planning Adjustments

  • Management describe any changes to planning scope and resources
  • Possible changes:
    • Business priorities
    • Adjustment to plan
    • Changes to scope
    • Movement of people

Team breakout #2

  • Continue planning based on agenda from previous day, making appropriate adjustments
  • Finalise team PI Objectives
  • Business Owners assign business value to the PI Objectives from low (1) to high (10)
  • Finalise the PI plan
  • Consolidate risks, impediments and dependencies
  • Stretch objectives provide the capacity and guard band needed to increase cadence based delivery reliability

Final plan review and lunch

  • Teams and Business Owners peer review all final plans
    • Changes to capacity (velocity) and load
    • Final PI Objectives with Business Value
    • Program Risks and impediments
  • All teams present their plans to the group
  • If Business Owners accept the plans, move one, else re-plan (after the review)
  • At the end of each team's time slot, the team state their risks and impediments
    • No attempt to resolve them in this short timebox
  • Present PI Objectives and Program Risks


Program Risks

  • Resolved in front of the whole train
  • One by one
  • Addressed with honesty and transparency
  • ROAM Categorised e*:
    • Resolved - agreed no longer a concern
    • Owned - someone has taken ownership since it cannot be resolved at the meeting
    • Accepted - some risks are just facts / problems that must be understand and accepted
    • Mitigated - plan identified to reduce the impact


PI Confidence vote

  • 'Fist of Five' technique used by everyone
  • If average is three or above, management should accept the vote
  • If less than three the team reworks the plan
  • Any person voting with two fingers or fewer should be given the opportunity to voice their concern
    • Might add to risks, require re-planning, or simply be informative


Plan rework

  • If necessary, teams rework their plans until a high confidence level can be reached.
  • This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.


Planning retrospective and moving forward

  • RTE leads a brief Retrospective of the PI Planning event
    • What went well?
    • What didn't?
    • What can be done better next time?
  • Next steps discussion and final instructions:
    • Capturing the team PI Objectives and user stories in the preferred Agile project management tool
    • Reviewing team and program calendars
    • Agreeing Daily Stand Up meeting times and locations
    • Reviewing locations for the iteration Planning meetings



RTE take away: Integrated PI Objectives

  • RTE and ART stakeholders summarise individual team PI Objectives into a set of Program PI Objectives




At the Program level each Feature (a service that fulfils a stakeholder need) includes a benefit hypothesis and acceptance criteria, and is sized or split to be delivered by a single ART in a PI. Features also lend themselves to the Lean UX process model which includes a MMF (Minimum Marketable Feature), benefit hypothesis and acceptance criteria. The MMF helps limit scope and investment, enhances agility and provides fast feedback.