PI Planning demystified

In our previous article we shared with you an Innovation & Planning sprint (IP) – concept that is coming in from Scaled Agile Framework® (SAFe®). Briefly we mentioned the Program Increment Planning (PI Planning). As this is a wider topic which, in our opinion, requires bigger attention and should be explained in more detail, here we come with it. We decide to implement a scaled agile approach when we have multiple teams (minimum 5) and together work on development of one product. Only then any scaled approach starts to make sense and only when having multiple teams, working together, we need a cross-team alignment and plan for a longer horizon than one sprint. SAFe® calls it PI Planning and it’s one of the best tools to synchronize, align and integrate between teams.

---

Is PI Planning different from Sprint Planning?

IP iteration ends with a two day PI planning event. This is also the last ceremony of a Program Increment (PI) which actually helps us to start another PI of 4-6 sprints of development work. It’s a crucial session and according to SAFe, if you don’t do it, you do not work SAFe. PI Planning serves as a heartbeat for teams and thanks to it we make sure that we plan and align towards common goals. The concept of PI Planning is in general very similar to Sprint Planning. Needs the same inputs and outputs, requires backlog refinement, business objectives teams commit to. The biggest difference is that it’s the whole Agile Release Train (ART) planning together and they do create one common board, identify and mark dependencies between teams and plan for a couple of iterations (typically in SAFe we can meet with 4 sprints + 1 IP).

The key inputs for PI planning are done as a part of preparations and the most crucial is the vision of the product and top 10 features that the Product Management team would like to have implemented. If we are already a more mature ART we can easier estimate the size of features and throughout the time we would know if during a PI our teams are able to deliver more than 10 or less than this. It will highly depend how big features are, we recommend to use T-shirt sizing method. As after a few PIs you will easily be able to answer if five medium & seven large are possible to be done. In case Product Management has a big appetite for delivering more, we can still easily negotiate as they are in priority order and we always focus on the highest ones. Main output of that event is an ART board that presents when we estimate to finish up with features that we commit to and highlight dependencies between them. On the board we would also mark down when milestones occur – we recommend to read on SAFe website an article about milestones, as they differentiate 3 types of them – PI, fixed-date and learning. Second, equally important deliverables of PI Planning are teams committed objectives provided with business value.

There are multiple benefits of that particular ceremony. Besides already mentioned alignment and cross team planning that goes smoother, we can say it’s a great networking event, which also integrates people who work on the same goal. It fosters the collaboration, transparency and good communication between teams and stakeholders. If possible we should aim to do it face to face and that also would help us to achieve more than a high level plan and committed objectives. Between the first and second day you can also have a dinner with all participants and some fun activities that would build and strengthen team relations. 

Preparations are key to achieve success

Each meeting requires proper preparations. Before PI Planning we need to remember about a few important items. Firstly, we need to have a refined enough backlog of new features that teams are going to work on in upcoming weeks. This is done mainly by a community focused around product: Product and Business Owners, Product Managers and other business stakeholders. They should focus on the highest priority features, MVP definition, bearing in mind what is the vision and roadmap of the product that teams work upon. The core of this preps is to remember about ‘just enough’ approach – it concerns not only the volume of the features but also the level of details and refinement done by people.

Secondly, couple of days before the event RTE together with Scrum Masters should agree the ways of working during the event. Make sure that required presentation and other necessary materials are ready. If we make an event in a space we don’t know yet it’s good practice to go and visit the place, check if we have enough space, think about acoustics and how teams will be sitting. From our experience we can tell that even if room is quite big, there’s always an issue with the lack of space on the walls – proper planning for this can help us mitigate that risk. We need to also order materials that we will be using, post-its in different sizes, markers, colourful shrink, tape, scissors, pens should be on your shopping list. A thing that would help teams in executing the event smoothly would be also backlog printouts – think how you can do it fast – in our project we have created a macro that hepes to download backlog from Jira and later on prepare it for printing in Word document with format adjusted to our needs.

The big day

Let us now dive into a by-the-book agenda for the PI Planning. It’s recommended that for a new ART this agenda is kept and the stakeholders understand the “why” behind all of these presentations. With every next PI the ART will mature and will understand more what is needed and how to achieve that through modifications of the agenda.

DAY 1 IN DETAILS

Business Context

In our previous article we described the importance of having a Business Owner and them being the people who have the power to push decisions forward, bring in the context of the portfolio or the entire company. They kick-off the PI planning with presenting the context, making themselves visible and creating the vision beyond what the ART is doing, but of what they are part of.

Product/Solution Vision

Next it’s the PM narrowing the same vision into something that the ART can focus on. Presenting the product vision and explaining the goal for the teams. The same vision, the same goal for everyone. A destination that the teams need to figure out the route to, on their own.

Architecture Vision & Development Practices

We had the product vision, here the architects will present and discuss the technical aspects of it. They will need to balance between intentional architecture and emerging design coming in from the teams. They will hold the big picture of the entire design and support the teams with guidance on the best practices. The biggest help they can provide is giving the input towards dependencies, both within the ART and outside of it with external systems.

Planning Context

Now, before we start the actual work, the RTE needs to present the particular ways of working for every team. They will go over all the necessary information needed for the planning to happen. Some things, like colour coding of post-its, may seem funny to some, but these are the boundaries that need to be created so that we come out of chaos into a process within which self-organising teams can collaborate and align with each other. The RTE, with the help of Scrum Masters, are the guardians of the process for better visibility, transparency, and efficient collaboration.

Team Breakouts

And at first there will be chaos. Remember that the ART consists of 50 to 125+ people and we want them talking to each other, discussing solutions and emerging with the plan of delivery. Teams will dive into their backlogs, elaborating on the acceptance criteria, estimating the workload. Scrum Masters will start preparing the spaces for the teams to present their plans. And slowly but surely the plan will start emerging.

It’s important that we don’t dive too much into the rabbit hole so the Scrum Masters will be vigilant that the teams don’t go into very long, detailed discussions. The plan does not have to be perfect and it’s crucial that everybody understands that it will change. We will learn through next sprints new things and those best laid plans will have to be adjusted. We are working Agile after all, aren’t we? However it’s important that we go deep enough so that we understand what the dependencies are, as any undiscovered one will hit us hard during the PI. So we want to discuss 80-90% of the features that we intend to plan and deliver during this PI – already on the first day. Your teams don’t want to be the ones that bring in crucial dependency to the table, on the second day of planning, while already everybody else has their plans laid out.

The teams put the stories and tasks to the board, figure out if the MVP for each feature and product is there. When they are sure they put the features to the Program Board and visualise the dependencies. Throughout the day they were discussing some risks and the Scrum Masters made sure they are noted and discussed, addressed properly, either within the team or with the relevant stakeholders, management. We formulate our plan with a set of goals – PI objectives.

Draft Plan Review

Now the teams present what they have accomplished during the first day, presenting the first artifacts of the PI planning which are the dependencies, risks and draft PI objectives. It’s crucial that everyone listens and gives feedback on what the teams might have missed, or they made some assumptions which are wrong, need to be corrected through someone’s input and that person has the responsibility to speak up and help. The team might also need some help with finalising the plan or making it better so they will address it here.

Management Review & Problem Solving

While we let everyone enjoy themselves after a hard days’ work – the RTE, PM, Business Owner and other stakeholders stay behind and try to figure out how to best support the teams. Input to the discussion are the observations from the day and the draft plan review. The group figures out the decisions, for example changes to the program backlog or to the solutions presented or mitigations to risks, that can make the plan more realistic.

DAY 2 IN DETAILS

During day 2 we finalise the plans, adjust the dependencies and discuss solutions.

Planning adjustments

This is the time to review and present the decisions and support initiatives, from the management review. Whatever was discussed has to be brought back and given to the teams so that they can adjust.

Team breakouts #2

Finalising the plans, reviewing and cementing the dependencies. Making decisions on final solutions. Not much time left before the ending plan review, that’s why most of the plan should be finished on day 1 and this time we are utilising to polish out the small things in items that need our focus, that will be critical to the plan.

This is also the time when we engage the Business Owners to evaluate our PI objectives and give us their estimated business value. There will be very valuable discussions between the team and the business owners while they will go into the details of the objectives.

Teams present their final PI objectives, risks and dependencies to the general audience.

Program risks

This is the final review of the risks. Here we use ROAM: Resolved, Owned, Accepted, Mitigated formula to decide what to do with them. These are the ART level risks as we would like the teams to self-organise and self-manage so what is within their scope or power should remain there. The ART level risks will be raised and owned by the RTE or the Business Owner that can help with them.

Confidence vote

Everyone shows their confidence in the plan with a fist of five – showing the number with their fingers from 1 to 5. RTE facilitates voting on the plan and calculates what is the general vote. A good confidence is something above 3, however we need to address it if someone has low confidence. They might have a critical piece of information that hasn’t been brought up yet and, if we aim to have a realistic plan, they need to be listened to, and those issues addressed.

Plan rework

What happens when the confidence is low? There is no best formula. You’d have to figure this out on your own. Hopefully this is a very rare occasion, as the RTE and others will circulate the room during the 2 days and try to address any issues coming up, working with the teams on a continuous basis, making them visible and finding help. If it still happens – work with what you have. If it’s online, maybe some adjustments can be done so that the plan can be rescued after spending another hour or two, if it’s physical you probably have to catch a flight and deal with it afterwards. Maybe it’s only one team that is having problems and they will have to replan, have an aligning session with a limited audience after the PI planning. Maybe some of the PI objectives should be moved to uncommitted.

Will the plan be perfect? It’s never going to be, regardless of the PI planning going smoothly or not, but you want to make it the most realistic plan there is.

Planning retrospective and moving forward

We want to get better and better and ideas on what is working and what is not you will always get from the teams themselves. Hence you need to ask, do a retrospective on the PI planning as well. Gather feedback and act on it on the next PI planning. Make sure to document everything and agree post PI actions.

Is it possible to do it all online?

Yes, it is. But it would never be the same. Since the start of pandemia we already had two such events, and we are preparing now for the third one. Luckily, our ARTs are already working together for more than 2 years and transition form face to face event to online one was a bit easier. However you loose the human aspect and the integration is very limited. It also takes longer time, as we need to switch between different virtual rooms and people cannot be focused for more than 6 hours being active on call. The role of facilitators is even more critical during online event, so make sure that the role is understood by Scrum Masters you work with. You can do PI planning online and achieve expected results of it, but to be frank it is not that great as the two day workshops held in one big room. The only advantage we see is that it is way cheaper, but when it comes to value you get from face to face meeting that is worth every money spent on it.

Possible modifications

SAFe is Agile, Agile allows us to adjust the framework to our needs and we can also play a bit with PI Planning. We should definitely have it but how we are going to do it, that’s another story. We can follow guidelines from scaledagileframework.com and when doing this for the first time we strongly recommend to follow the instructions given by SAFe. From first PI planning look at the retrospective and then start thinking about some improvements and maybe modifications so you can adjust this event to your ART needs.

One of the examples we faced in our ARTs was that after few PIs some people from teams started to say that on confidence vote it is the best to give minimum 3, otherwise they would need to tell why they do not believe in the plan. This was an obvious antipattern that required more attention and some other actions around courage and collaboration, and removing this wasn’t quick and easy. However, we thought that voting could be semi-opened. We bought plastic balls and put in the room 5 big boxes, everyone was taking a ball and putting it to the box with a number he/she really thinks about when it comes to plan commitment, we calculated the average based on the number of balls in a given box and asked openly a question if someone would like to say something about his/hers doubts when it comes to the prepared plan.

Nothing beats an Agile team

“There is no magic in SAFe… except maybe for PI Planning“

SAFe Authors

We fully agree with that statement. Multiple teams come together to refine the product vision, align towards the same goal, collaborate on solutions and create a realistic plan. It’s an Agile ceremony like none other, during which we see that out of all that chaos a plan emerges and a common understanding of where we are going and that we are actually going there together as a Team of Teams.