Don't "big batch" PI Planning

Smaller batches go through the system faster with lower variability, right? We should all be familiar with SAFe Principle 6:

“Faster feedback is one of the primary reasons for working in smaller batches. The smaller the size, the faster teams can collect and evaluate the feedback to adjust. In addition, smaller batches reduce WIP by limiting the number of requirements, designs, code, tests, and other work items moving through the system at any point. Smaller batches go through the system faster and with less variability, fostering faster learning. Moreover, since each item in the batch has some variability, larger batches accumulate more variability” ( ? Scaled Agile, Inc.)

So, I guess my question is, why don’t we apply this to PI Planning? Let’s consider a few options.

1. Don’t big batch Management Problem Solving?

Management Problem Solving takes place at the end of Day 1 after the Draft Plan Review and is more likely to take place sometime early evening. But why would you want to wait until the end of a very long and intense day to consider some of the challenges that the teams are encountering? The management team are present throughout Draft Planning so why not get them to solve some of the problems during that afternoon session??

What I have found very effective is to create a board where any member of the team can pose a question to the management team as they undertake Draft Planning. The RTE can regularly review the board and make sure that the appropriate members of the management team ‘resolve’ the problem.?

Does this mean that we don’t need a Management Problem Workshop? No, because we still need the management team to consider some of the problems from their perspective (not just the teams) but my experience has been that this reduces the time needed for this session so that we can all head off home or back to the hotel!

2. Don’t big batch the ART Planning Board

So I often see with teams and particularly the Scrum Masters that they won’t transfer their Team Boards to the ART Planning Board with their complete Features until the end of Final Planning when their plans are just about completed. It is almost like they don’t want to share or commit to a feature until the last possible moment.?

This causes several issues.

Firstly, if you have 10 teams trying to complete the board at the same time it often resembles a ‘scrum’ of Scrum Masters all trying to complete the ART Planning Board.

Secondly, it gives no visibility of the progress throughout the planning sessions.

Therefore, before PI Planning I gather all the Scrum Masters together and set the expectation that as a Feature is completed on the Team Board then it is transferred to the ART Planning Board. That does not mean that it can’t be moved but it does create an iterative view of the ART Planning Board and an early view after Draft Planning that can be considered by the Management Team in the Problem-Solving session.

3. Don’t big batch the Confidence Vote

As a RTE you want to create a Psychology Safe environment none more so when it comes to the Confidence Vote. You want people to be able to give an honest assessment of their team’s confidence. However, as the RTE, you have to be very careful when you approach the first table and one team member holds up a 2 or even a 1!! You have just spent the best part of 5 or 6 hours planning and NOW you are telling that you have no or little confidence! WHY?

You can’t even show this frustration in your facial expression. That’s why I don’t like leaving the Confidence Vote until the end.?

So, on Day One at the last Coaches Sync in Draft Planning, I ask the Scrum Masters to get an indicative view of confidence and share it with me.?

This is excellent intel for the Management Problem-Solving session but more importantly, allows the management team to try and restore confidence before getting to Confidence Vote.

I also do the same on Day Two at the last Coaches Sync in Final Planning as the last responsible moment to see whether we could overt a no-confidence vote.?

If not, I always check with the person that they are happy to represent themselves at the Confidence Vote – it can be quite intimidating standing up in front of 100 to 150 people saying that you have no confidence in your team’s plan.?

4. Don’t big batch Risks

You must have been there when the RTE stands up at the end of the Final Plan Review and then goes through each of the risks asking if is this, Resolved, Owned, Accepted or Mitigated and if Owned who is the owner? If there are a lot of Risks, then this can become a tiring session, and I can feel the energy in the room wane.

Instead as the RTE I constantly review the Team Boards throughout Draft and Final Planning and start collecting the Risks and move them to the ROAM Board updating them throughout both sessions.

Then when it comes to “ROAMing’ the risks you are just summarising the decisions and checking that each risk has been correctly categorised.

5. Don’t big batch the Retrospective

The final ‘don’t big batch’ is the PI Planning Retrospective. At the end of two days of planning, I then announce that I want to do a retrospective the folks in the room look at me and say, ‘We just want to go home.”

I have tried all sorts of different ways to complete the retrospective. – feedback forms, Survey Monkey. But the most effective is that on every exit door, I place a ‘happy face’ a ‘meh face’ and a ‘sad face’ on a Post-it Note

At every interval (coffee, lunch etc) I ask people to write a post-it note with feedback on the door.

That way I have a chance to resolve some of the sad post-it notes on the fly during the current PI rather than wait until the next PI!?

Summary?

These are my top 5 ‘don’t big batch’ but are there other examples where you have created smaller batches?