PI Planning

Accredited by The Leading Bodies

Introduction

You may have heard of a new phrase in Agile Town, “PI Planning” mentioned via whispers and sometimes in large groups of agile enthusiasts! I here you say, “what is this blasphemy! Planning! We don’t do planning in agile!”

This is one of the biggest misconceptions of agile and shows a poor understanding of the original agile manifesto:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

And that’s what PI Planning is! It’s a big two-day workshop where all the individuals plan and commit to a set of objectives that are time-boxed to two months (roughly…) It was developed by the clever people behind the SAFe® framework (SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc). So your probably wondering, “how many people attend?” It can be from 50 to 150 individuals.


Who attends?

It’s not just developers who attend, we also need some business folk who can paint a picture of the future product vision – this is one of the key principles behind the agile manifesto:

“Business people and developers must work together daily throughout the project”

We probably also need a coordination layer to support five to ten agile teams:

  • A Chief Scrum Master – he is called the Release Train Engineer (RTE)
  • A Product Manager – a product visionary, a true leader and savvy business man
  • A System Architect – someone to lay out the architectural runway and guide the many technical teams in the development

All these individuals work together over the two days to create a strategy that will guide the next two months’ worth of work. Fun right?


How do we plan with so many individuals?

This is a critical point as it would be a good idea to have a two-day agenda of some sorts. And our good friends at SAFe® have done just that!

This agenda is executed by the coordination layer to keep the two-day planning process time-boxed. Each slot has its own specific purpose and a reason why it’s there, lets break this down further…

  • Business Context – CEO describes current company strategy, vision and generally “pumps” everyone up for the two days.
  • Product Vision – Product Manager describes the vision of the product and brings forward the top 10 features to plan
  • Architectural Vision – System Architect describes current systems and future architecture. It’s also a good idea for UX/UI to introduce any high-fidelity prototypes to visually help with the planning process.
  • Planning context – RTE describes how planning will be conducted.
  • Team Breakout – Scrum or Kanban teams break out into their own groups and plan out individual features they have selected.
  • Draft plan review – a DRAFT presentation of team’s capacity, load and objectives that they will commit to.
  • Management review – RTE, Product team, Scrum Masters and Business Owners meet at the end of day one to discuss any changes to scope, priorities, risks and dependencies.

WOW, that was day one…and yes, we also have a day two agenda:

  • Planning adjustments – based on the previous night’s management meeting, any updates are described.
  • Final team breakout – teams solidify their plans, any dependencies are managed.
  • Final Plan Review – teams present their final plans and committed set of objectives.
  • Program Risks – Any risks are managed and dealt with.
  • Confidence vote – Teams vote on how confident they are with their plans.
  • Rework – Any teams that need extra time or were not confident with their plans are instructed to keep planning until they can commit to set of objectives.
  • Retrospective – Quick session at the of the day to capture how well the two days went, what could we do better, etc.

And that’s the end of day two!


What have we achieved?

Well, if you have spent the last two days collaborating, building and planning, you would by now have a very good idea of the direction you are heading in and that you are in alignment with the business plans.

The teams are also more empowered because they themselves have made decisions on how they will proceed in constructing this product:

“The best architectures, requirements, and designs emerge from self-organizing teams”

The business also has a good idea what features have been committed to and what to expect within the next two months.

And the most important aspect is that everybody who attended this event has embraced the product vision and supported each other:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

The coordination layer also can synthesis the individual team objectives to construct the overall PI Objectives that can be presented to board members and business owners.

Suhayb Mahmood


How can I do this?

If you want to set the stage and conduct the above masterclass in large scale collaborative planning, why not attend one of our Leading Safe Courses that will teach step by step how to achieve the above.

Check out our Leading SAFe Course