BRP: What all you do in Big Room Planning

How BRP helps you to make your delivery smoother and better

‘Plans are useless, but planning is indispensable.’ Same goes with planning in Agile. Usually in software delivery, we do different type of planning. Like annual planning, release planning/quarterly planning/PI planning and finally sprint planning. Though agile is all about empiricism but planning is an important aspect in delivery.

Today I am going to discuss about ‘Big Room Planning’ based on my experience and understanding. There are various other terminologies used for similar kind of planning. Like release planning which is typical planned for specific releases. Here number of sprints decided based on the smaller releases. It may be somewhere around 6–8 sprints (considering sprint is of 2 weeks). Similar planning event in SAFe is called as PI (Program Increment) planning.

Photo by Jason Goodman on Unsplash

Now what format of Big Room Planning (BRP) I have experienced is basically planning for a quarter. For each quarter, Big Room Planning happens in the last month of previous quarter. This planning usually goes for 2 days where all teams plan for next 90 days and present to leadership and other teams, get their feedback and adjust their plans according to that. Here I have divided this whole event in three phases i.e., Preparation, execution, and outcome. Let’s see what we do in each of these phases.

Preparation

There are various preparations steps involved before we go for Big Room Planning.

1. Capacity Planning: — It is important to know how much capacity is available for upcoming quarter, based on that only work should be planned in each sprint. Whichever sprint team availability is lean, less work should be planned for that sprint and whichever sprint capacity is full, may be work can be adjusted to some other sprints based on discussion with team. Scrum Master for each team should collect team’s availability plan or long leaves for next quarter. It can be done in some tool or in a shared excel sheet also to keep it simple.

2. EPICs/Stories Creations: — EPICs and stories creation gives clarity on scope of work and high-level roadmap for next quarter. Usually POs/teams would not have complete details of the work for next quarter, but still EPICs and stories should be created with high level details (try to have a target of story creation of around 85–90%). These EPICs and stories should be created in Jira or any other tool which is used to capture and track all the requirements.

3. EPICs/Story Walkthrough to teams: — This step is dependent on step 2. Until unless you have EPICs and Stories created, you would not be able to give walkthrough of the requirements to team. Though it would be high level and would still need to go through refinement but still would give team a good overview which would help them to decide on estimates and dependencies/risk involved.

4. OKRs: — You may have OKRs defined or may not have. But it’s a good way to align organization and team level goals.

5. Risks, Impediments, Dependencies and Assumptions (RIDAs) :- Teams are encouraged to identify RIDAs in advanced before going to BRP. This will help them to prioritize the work and adjust their plans for next 90 days.

Execution

Agenda — Day 1

1. Kick off Meeting — Day 1 starts with kick off meeting of Big Room Planning. Here product managers would present their plan for this quarter, technical architects would talk about any changes in architecture. Higher management would give road map for next quarter or 90 days. It is usually a quick meeting for around 45–90 mins. Post that teams would go for breakout sessions.

2. Breakout Session — This time is dedicated for team to plan for next quarter. Here PO owner would give walkthrough of EPICs, Features and stories planned for next quarter. Team members would clarify their doubts, raise risk and dependencies, would decide high level story points and map stories to right sprint. So, the outcome of this breakout session is sprint wise plan for next 90 days based on priority and capacity and identified Risks, Impediments, Dependencies and Assumptions (RIDAs). Team would use some tool to showcase this plan, like mural or confluence (or excel sheet).

3. Presentation of 90 days plan — Once teams are done with breakout session, they would be going for presentation of the 90 days plan to all stakeholders (Higher management, Product management, business, other teams etc.). Post presentation teams would receive feedback from stakeholders based on priorities, RIDAs and other factors. Team would take up these inputs and if needed, would revise their plan in breakout planned on day 2.

Agenda — Day 2

1. Breakout Session to revise 90 days plan — Based on the inputs received post day 1 presentation, if needed team would revise their 90 days plan. They would revisit their sprint wise plan, story points and RIDAs accordingly. Post this session team would their revised 90 days plan.

2. Presentation of revised 90 days plan — Teams who went for revision of their 90 days plan, would present again here. This plan would have inputs accommodated provided on previous day.

3. Vote of Confidence — Once presentation is done from all the teams, there is a vote of confidence to determine how confidents teams are on completing the committed work. It usually depends on the RIDAs. Teams confident would go up or down based on the challenges they are seeing in implementing the 90 days plan. If teams show lower confidence, that means there are challenges which they feel can have critical impact on their plan and they are looking for some support from higher management or stakeholders. Vote of confidence is a good way to know team’s pulse.

4. BRP Retro — Retro is the last thing you would have on day 2 of BRP. This retro is more about what well during BRP, what didn’t go well in BRP and what action can be taken in next BRP to do it better. Usually, it is retrospection about how backlog got readied for BRP, how RIDAs identified and raised and how the overall planning looks like. Based on the actions, action owners can be decided, and same actions can be reviewed in next BRP retro.

Outcome of BRP –

1. High level roadmap for business unit for next 90 days

2. High level plan for next 90 days for all teams based on priorities and capacity

3. Clear identification and mitigation plan for RIDAs (Risks, Impediments, Dependencies and Assumptions)

Hope this information would help you in your agile journey. Thanks.