Effective PI Planning

A?Program Increment?(PI) starts with a time-boxed?PI Planning?event in which?Agile Release Train?responsible for planning & delivering incremental value in the form of working, tested software and systems . This is a two-day event where all stakeholders (including Agile/Scrum Teams) on the?Agile Release Train (ART)?participate in a collocated event. All teams have their own areas setup for their planning together with a Program Area with a Program Board to map Feature delivery and dependencies across teams. PI are usually?8 – 12 weeks?long.

Purpose: The purpose of?PI Planning?is to create an emergent roadmap to deliver a prioritized and agreed set of outcomes as well as identify both known and potential impediments to progress. The goal is to align business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.

Goals:?The primary purpose of release (PI) planning?is to gain alignment between business owners?and program teams on a common, committed set of?Program Objectives?and?Team Objectives?for the next?release?(PI) time-box.

Features: Have clear, simple, well-written business oriented and valuable features rather than Features describing a technical solution.

PI Planning Inputs (Pre-Work)

• Product backlog features prioritized & ranked.
• Business review of each feature completed
• Technical analysis done, feasibility established, architecture and solution understood,?enabler?features identified.
• Features ranked (for example using?WSJF) – single common stack for the entire program
• Features sufficiently defined to support release planning and estimation.

PI Planning Process Steps

• Mapping: Features elaborated into user stories
• Sizing: Stories estimated (to +/- 20%) via bulk estimation
• Scheduling: Initial allocation of stories to sprints, taking into account team velocities and dependencies.
• Feature delivery dates determined (to nearest sprint)
• Release scope set based on velocity and target release date.
• Consolidated release plan showing feature completion dates.

PI Planning Outputs

• Release scope defined for next time-box
• Team better comprehends the objectives for the whole PI.
• Shared understanding of what it takes to release
• Program risks reviewed and actions identified to solidify the plan
• Release objectives reviewed and scored by business stakeholders
• Team and program confidence vote on the plan
• Collective ownership of the plan

Day 1: Creating Draft Plans

Business Context: This is an update given by upper management or a business on how the business is doing and how well they are keeping up with the market and the consumer needs.

Vision: This is overall business vision and objectives, but also the vision for the upcoming PI. At the beginning of PI Planning, the vision will be presented by Product Management or a senior business sponsor for the Agile Release Train.

Architectural Runway:?Understanding the architectural implications of upcoming Features is important to ensure that the teams have an understanding of the underlying architectural approach and system constraints that they have to work within. Systems Architect or IT department will outline the systems and architecture vision for improvements to the infrastructure that will help to improve the time to market and may impact development during the coming PI.

Planning Context & Lunch: The Release Train Engineer (RTE) outlines how the PI planning process will work and what is expected from the teams and the overall meeting.

Team Breakouts: Teams will gather around the boards to estimate their velocity for each iteration and look over their backlogs and what will need to be brought forward to support the features outlined in the vision.

Draft Plan Review: This is a time-boxed meeting where the teams present their draft plans so that business owners, product owners, stakeholders and other teams can give feedback.

Management Review and Problem Solving: In most cases, the draft plans will bring up issues with architecture, scope, and people and resource constraints. These issues can sometimes only be solved by management renegotiating scope and possible features.

Program Backlog should be sufficiently refined to support story writing and sizing. Each team will first create draft plans & these plans include 3 basic things: a feature delivery timeline, a set of PI Objectives, and a risk assessment.

Create Stories from Features:?Known as Story Mapping – taking a set of features and breaking each one down into small slices of functionality that can be delivered in a single iteration. At this stage it is not necessary to refine the story to the extent that it will meet definition of ready. This refinement can be done as part of the backlog refinement process.

• Capture the end-to-end user process flow.??Consider these as functional steps or ‘features’.
• Start defining potential actions the user will take to accomplish each function. These can be considered the ‘user stories’.
• Create the “MVP”.
• The classic?INVEST (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable) ,?DEEP , and?3C’s (Card, Conversation and Confirmation) ?technique apply as much, if not more, to Features than they do to User Stories.

Story Size Estimates:?estimation by linear affinity. This method?is good for generating initial estimates for large Product Backlogs, e.g. for PI Planning. Stories not necessarily fully defined (Ready). Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended)

1. Planning Poker – Agile Estimation Method
2. Bucket System – Agile Estimation Method
3. Affinity Estimation – Agile Estimation Method
4. Dot Voting – Agile Estimation Method
5. White Elephant Sizing – Agile Estimation Method

Story & Feature Scheduling: In this step allocate stories to sprints by taking into account story size (in points) and team velocity (points per iteration).

Identify Risks and Dependencies: Dependencies constitute risk in that they represent items on which the team has no direct control over.

Align Team Deliverables with Program Objectives: It gives teams the opportunity to validate with stakeholders that they have clearly understood the intent and priorities defined for the PI in terms of business value.

• This step is about assigning overall business value to the PI.
• The intent of this exercise is to summarize the PI in terms of meaningful business objectives, and to confirm alignment between teams and stakeholders. Features deliver benefits that are aligned with business goals.
• PI objectives should be?SMART: Specific, Measurable, Achievable, Realistic, Time-Bound.
• Business stakeholders circulate and score the team’s objectives, assigning a ‘business value’ between 0-10, where 10 represents the highest business value. Each team starts with their most valuable PI Objective as a ’10’, then all remaining PI Objectives are scored relative to that first 10. BV can either scored as relative within the team, or relative to the overall train.
• At the next PI planning event, following the PI demo’s, business stakeholders will rate objectives based on what was actually achieved – this data is the basis of the Program Predictability Metric. (Pass out a printed list of PI objectives with original rankings to the stakeholders with additional column for actuals).

Leadership review & problem solving: The leadership team will work on the following questions:

• What have we learned so far?
• Where do need to adjust: Vision, Scope, People?
• Where are the bottlenecks?
• What features must be de-scoped, or deferred?
• Decisions needed before tomorrow?

Day 2: Make Adjustments and Finalize Plans

The leadership team will announce any required changes to feature priorities and team changes.

The overall agenda for the day will look like:

• Program adjustments from leadership review – priorities, scope changes, people movements.
• Teams adjust & finalize plans
• Stretch objectives setting
• Teams identify remaining issues needing help from outside team
• Business stakeholders circulate to review plans and score PI Objectives
• Team-level confidence votes.
• Program wall-board: Feature delivery timelines by team.
• Team plans collected to front of room, risks?ROAM’ed, program confidence vote.
• Event retrospective.

Program Adjustments?–?The day begins with any adjustments or decisions that were made by management and stakeholders in the problem-solving meeting.

Team Breakouts 2?– Plan Adjustments to incorporate changes in priorities, scope, people moves into their plans. This will include any scope changes and with feature delivery timelines, updating the team’s list of risks, and potentially revising the teams list of program objectives. Identify any ‘stretch objectives’ and add them to their list of program objectives.

Scoring PI Objectives –?Business value is assigned to each objective (scored 1-10). Formulate objectives by thinking about the problems that are being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic ‘value statement’ and from there back to at least one of the strategic themes identified for the business.

ROAM’ing exercise on their list of risks

• R: Resolved. The team has resolved (or knows how to resolve) the risk.
• O: Owned. The teams decides to ‘own’ the risk, that is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.
• A: Accepted: The team accepts the risk as something that is ‘part of life’, or part of the cost of doing business.
• M: Mitigated: The team believes they can take specific actions to reduce the impact of the risk.

Program Wall Board Update

The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of features completion dates, enabler items, dependencies and major program milestones.

Program Confidence Vote

It is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially re-worked until all team members vote at least a 3.

PI Planning Event Retrospective

It can be as simple as a 2-column table drawn on a whiteboard or flip-chart with a column for ‘what went well’ and another for ‘needs improving’. A?Dot Voting ?exercise can be done to identify the issues most important to the gathered teams.

Benefits of PI Planning

• 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 and 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 Work in Process (WIP)
• Fast decision making

Frequently Asked Questions

1. Who are the participants of PI Planning?

Answer:?All the teams of the Agile Release Train, Scrum Masters, Product Owners, Developers, Stakeholders, Business owners, Suppliers, Users, & Customers.

2. Who conducts the PI Planning session?

Answer:?The?Release Train Engineer (RTE) ?is at the front of facilitating the PI Planning session and ensures that a seamless and smooth PI session is done.

3. What are the Challenges of PI Planning?

Answer:?PI Planning?does have its huge benefits but at the same time it can have some challenges. Some of them are listed below:

• PI Planning is long and can become boring at times so it is better to find creative and innovative ways to make it a little engaging.
• Trusting can be difficult and may appear as a challenge to them.
• Maintaining collaboration and synergy of multiple Agile Teams in the Agile Release Train, is vital towards achieving the objectives in the Program Increment.
• When doing the vote of the confidence, many people can feel pressured to vote.

4. What is the difference between a PI Roadmap and a Solution Roadmap?

Answer: PI Roadmap?is created before your PI Planning event, and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:

1. The current increment (work that’s committed)
2. The next forecasted increment (planned work based on forecasted objectives)
3. The increment after that (further planned work based on forecasted objectives)

The?Solution Roadmap?is a longer term forecasting and planning tool for a specific product or service usually covers few years, with more specific details available for year one (like quarterly features and capabilities), and more general information (like objectives) for year two and beyond.

5. What is Post PI Planning?

Answer:?Post?PI Planning?session ensures that you have a finalized set of?PI Objectives?that have to be implemented, all the expected dates and milestones for delivering the final increment. These are mapped on to a physical or a Digital Solution Board.

The Release Train Engineer explains and discusses the objectives, dependencies, impediments and the risks of the PI. Risks are identified and mitigated, using the ROAM technique. If there are any aspects of the planning session that are left or not clearly understood, then a Rework Session is held to review the plan with the Agile Release Train.