Planning Agile Part 2: Big Room Planning
Last month I wrote about Agile Central’s Planning Calendar and the lead up to our Big Room Planning event. Now, I will dive deeper into the week of Big Room Planning and the event itself. Namely, I’ll focus on how we set up, what our schedule looks like, what we plan to get out of it, and how we set ourselves up for success.
This article is written from the perspective of our Agile Central engineering department. However, we also hold Big Room Planning events for marketing, sales, leadership, services, and other groups at Agile Central and across CA. So if you’re not in engineering, this article is still for you!
What is Big Room Planning?
Big Room Planning (BRP), sometimes referred to as PI Planning, is a two-day, department, or release train, planning event. The purpose of the event is a collaborative planning process resulting in a committed roadmap for the Planning Increment (PI). At Agile Central, our PIs are fiscal quarters, organized into six or seven two-week sprints, with all teams on the same sprint cadence. The final sprint of the quarter is really two, one-week sprints; one for Hackathon, and one for the Big Room Planning event.
Before the Event
While the Big Room Planning itself is only a two-day event, teams spend much of the full week on planning related activities. The two days before Big Room Planning, always Monday and Tuesday for us, teams work to understand the priority and break down of features as they relate to our PI goals. Our teams will generally block out three hours each day to:
- Establish their capacity using historical velocity and team judgement
- Product/Architecture/Initiative teams will provides a compelling, prioritized list of features with specific defined outcomes
- Work, to the best possible extent, to do initial story breakdown and any necessary spikes for these features. Alternatively, create spikes scheduled for early in the quarter.
We open every Big Room Planning with our stated purpose and outcomes, working agreements, agenda review, and context setting. This includes presentations from product, architecture, and engineering, and time for questions from the release train. Our invited customers introduce themselves and let us know what they want to get out of attending. That way we know what they are interested in and which teams are best for them to observe.
Example purpose and outcome statements:
“To gain alignment between product, architecture, and delivery teams on a plan to achieve our Agile Central goals for Q1 2018. By planning and estimating the work necessary to achieve our team objectives, understanding our risks, and collaborating with other teams on our dependencies. So that we can achieve our Q1 business results for Agile Central.
Once Big Room Planning is completed, we will update our customer-facing roadmap. We will share this roadmap with the Sales Organization. The quarter objectives and planned features will be represented in Agile Central and shared with the organization.”
For more on purpose, check out “The Top Three Reasons to Hold BRP.”
1) Welcome and High-level Agenda (15 min)
- Review Purpose, Agenda, Working Agreements, and Tools
- Customer Introductions
2) Setting Business & Strategy Context (20 min)
3) Q1 Product and Architecture Goals (20 min)
The rest of the morning, takes us through a working lunch to 1 pm, and is spent in team breakout session #1. In this session teams:
- Do a reality check around their goals and features
- Identify risks & dependencies, adding them to Agile Central for visibility
- Complete a team breakout template to help the Product Owner (PO) read out to the larger group after lunch. The template includes:
- Team goal
- Customer value
- Business Value
- Key results and measurements
- List of features, initiatives, and outcomes slotted into capacity planning
- Risks and dependencies
- Team confidence vote
When we return, we take an hour to hear from each team and ask questions. After readouts, teams have a second two-hour breakout session to refine their plans. During that time, the leadership team stays in the room to ROAM (Resolve, Own, Accept or Mitigate) the risks that came out of the first breakout.
After the second breakout session, Leadership takes 30 minutes to discuss the results of the ROAM, any actions that came of it, and any related changes to the plan we should prepare for in day two.
The Release Train Engineer (RTE) runs a quick retrospective exercise on the events of Day One.
End of Day SWARM
After the extended team is excused for the day, Product Managers, Architects, UX leadership, VPs, and Directors stick around for a quick SWARM to assess if our plan lands us our Business Objectives and determine recommendations for Day 2. While some recommendations will result from the ROAM, a discussion at the end of the day illuminates potential changes or solutions that are not easily surfaced earlier in the day.
The first half hour is dedicated to reviewing the agenda, announcements, and discussing any recommendations that resulted from the previous evening’s SWARM. Teams then have two and a half hours for their final breakout session to:
- Assess what needs to change from swarm recommendations
- Answer what is blocking their ability to reach commitment
- Fill out the Team Breakout Template for their final plan
The whole train comes together once more after the last breakout to share their final plans. We ask more questions, and ROAM additional risks that have surfaced. At this point the train assesses if the plan is far enough along to commit, or if a fourth breakout is needed. If a fourth breakout is needed, we repeat the Day 2 morning schedule. Otherwise, the entire train takes a vote of confidence using the “fist of five” method. When every person on the train votes three or higher, we have a plan! If not, we address the concerns of the people who voted below a three, and potentially use the fourth breakout session to get to alignment.
Once the vote passes representing a committed plan, our customers come up once again to offer “gifts and greats” — a”gift” to the train for how we can improve in the future, and a “great” they will take home with them for improving their own working environment.
We close with appreciations, an exercise created by the late (and very wonderful) Jean Tabaka. This time allows individuals to stand up, look a person in the eye, and thank them in front of the train. Appreciations can be about planning, the previous PI, or anything else you are thankful to that individual for. We also encourage everyone to write feedback on sticky notes to leave on the wall on their way out. The Scrum Masters use this information to retro on the event together.
If we finish early on day 2, we celebrate that afternoon. When we need a fourth breakout session, we have a celebration the following day. This is a time for us to celebrate our successes and to share social time with our teammates. Past events include renting out an ice rink and bowling alley for the afternoon.
Ultimately, the week of Big Room Planning is resource, time, and emotionally heavy for the train. Our success depends on several main factors woven throughout our process. These factors are trust, preparation, and agility.
Without trust across all roles on the train, this event will not be successful. Teams must trust product and leadership to understand and prioritize work in advance of the event. Leadership must trust teams to break down and size work in a way that will reach desired outcomes. Individuals must trust everyone in the room to hear, take seriously, and work through risks and concerns during the event. This is not easy. Trust like this is more easily harmed than it is built. Years of trust can be broken in one bad BRP. Ultimately, trust must be demonstrated first by leadership. You need a leadership team that will take the blows that come with building trust gracefully – a team that acts as an example of a culture of trust, in order to be successful.
It is no coincidence that I published the calendar as Part I of this series. The entire train must be prepared to have a successful Big Room Planning. If features are not ready, and train goals are not understood, Big Room Planning will not succeed. Time to understand, align, and think through problems in advance prepares us for tough conversations, and making practical trade offs, knowing that the result will get the train to it’s goals.
Ultimately, we hold Big Room Planning to be agile. All involved must understand that no plan is set in stone. Not all risks are known before work starts, and outside issues can occur that may require steering or a pivot. It is in trusting our ability to be agile, in our regular steering, planning, demos, and other ceremonies, that prevent this process from turning agile into waterfall. Ultimately it is time and budget that are constrained in a PI. Scope is what will change, and it is our agility that ensures our outcomes are successfully met when that happens.