The temperature is beginning to release us from the dog days of summer, the leaves are starting to change, and of course Pumpkin Spice is back on the menu just about everywhere you go. This can mean only one thing. Yep! It’s strategic planning season heading into Q4 … a.k.a PI Planning time.

Why the focus on this topic here today? What role should Product Management leaders play in the overall process? What is necessary from a preparation standpoint, and what should be expected with the output?

Today we’ll explore the high level context of the PI Planning event (lots of good sources out there for this topic), but really where I want to focus the discussion is around what I believe are the 5 essential questions every product manager should be asking as they head into discussions. Let’s dig in.

Definition/Overview

I’ve not found a distinct definition per-se of the term PI Planning, but conceptually there are many sources out who provide a good overview. Here are just a few:

• Scaled Agile Framework (© Scaled Agile, Inc.) – Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams to a shared mission and Vision.
• Planview – The PI Planning event is two days of focused planning with all the teams, stakeholders, and product owners/managers in one place to review the program backlog and determine the direction of the business. 
• PMWorld Journal – PI Planning is a whole team event where the whole program – the set of smaller agile teams working closely together as a single team-of-teams – come together in a big room (hence it is often referred to as Big Room Planning) to agree a plan for the next 8 – 12 weeks. The goal of the event is to create alignment, encourage collaboration, enable self-organization, eliminate waste and exploit the synergy between the teams.

Goals, Benefits & Structure

I can’t state the goal any better than what was outlined above … create alignment, encourage collaboration, enable self-organization, eliminate waste and exploit the synergy between the teams! Love it!

From a benefits standpoint, I think Scaled Agile Framework summarizes it best with these points

• Establishing face-to-face communication across all team members and stakeholders
• Building the social network the framework 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 and eliminating excess Work in Process (WIP)
• Fast decision-making

And finally, in reviewing the main points from the goals and benefits, the structure needs to include

• Executive briefing – A briefing that defines the current business context
• Product vision briefing(s) – Briefings prepared by Product Management, including the top 10 features in the Program Backlog
• Architecture vision briefing – A presentation made by the CTO, Enterprise Architect, or System Architect to communicate align on architectural direction

Our Role as Product Management Leaders

Now comes the fun part. Part 2 of the structure mentioned above is the Product vision & briefing. What does this entail? In my experience, if you can answer these 5 questions leading into the event you will be well prepared.

1. The Universe of Asks – when it comes to the work to be done, what is being asked of you? And where is this information being managed for review (regardless of how good you think you are, this can’t be managed in your head).
   • New capabilities – this is where our natural inclination lies … what capabilities will help drive revenue or create buzz in the marketplace or around the company?
   • Technical debt – but you can’t forget about the plumbing. A few ideas include what architectural adjustments are needed, or what software upgrades are needed. There are plenty more not listed, and the Product leader should work directly with the Development leader to understand what they are and compromise on what % of the work should be focused here.
   • Compliance – what new regulatory changes need to be accounted for?
   • Rollover – this is also something people forget … what work didn’t get completed in the prior quarter?
2. Prioritization – what are the priorities of those asks? How do they stack rank against each other? I’ve posted on the mechanics of this in my post Prioritization, Complexity, Cost of Delay and other Musings, so if you are interested follow the link for more details. But in general
   • What are the tangible benefits of doing the work and/or the opportunity cost of not doing the work? (revenue, cost savings, efficiencies, time to market delays, etc.).
   • In other words, be able to justify why you have prioritized the work the way you have in an objective/calculated manner leaving few questions and/or doubt in the mind of the audience.
3. Capacity to take on the work – essentially this question goes to the make up and cadence of the team. How much work can the team be expected to do?
   • Team construct – how many people are on the team? How much work can they take on in any given Sprint (usually measured by story points)?
   • Velocity – what has been the throughput of the team on average? How many story points per Sprint are anticipated given historical trends?
   • Committed v. completed – it is important to understand how much the team says they can do vs. how much they actually deliver. This is where rollover comes from, and if not managed correctly can have a detrimental impact to future Sprints.
4. Size/Scope of the work – whereas point #3 really should come from the Scrum Master/Development Leader, point #4 is the responsibility of the Product Leader (with input/assistance from the development team). Essentially, do we know how much work we are asking the team to do?
   • Tracking – Is the work defined in Jira, AZDO, etc. at an Initiative/Project/Epic level?
   • Scope – are the proper Features/User Stories broken down and clearly communicated (including acceptance criteria)?
   • Size – Have the Features/User Stories been reviewed with the development team, groomed, and appropriately sized?
5. Fit – Have we aligned the prioritized list of work to be done (e.g. – point #4) against the perceived capacity of the team (point #3)? Is it mapped out by Sprint (at least the first several in the quarter)? Is it reasonable and does it fit?

Hope this provides keen insights as you approach your own quarterly strategic planning efforts.