Refinement – preparations for big room planning

If you are running some kind of big room planning pulse, the preparation you put in is half the success. The last thing you want to do is to round up 10 senior team members and turn up with a feature described solely by a one-liner “next gen product”.


Before I go into details of what a good baseline setup should be in terms of preparations, let’s set some context. Imagine you have multiple development units (“release trains” in SAFe lingo, “Requirement areas” in Less) in which you have 5-10 teams.

Choice #1 – choose the same cadence

First choice (which you should do before launching release train #2) is to align the cadence. This basically means that the preparations happen at roughly the same time across all release trains. This is essential so as not to create a coordination “mission impossible” for the people who need to do such things, especially for PM’s and PO’s whose day job will shift from “virtually impossible” to “reasonable” if you pull this off.

There is an edge case here when you don’t need to do this, and that is if each release train is able to work independent of each other. That’s desirable, but a very rare occurrence in real life. So this post will follow the principle “optimize the normal, treat the exceptional as an exception” and assume you have dependencies for features and epics across release trains.

How it works

Refinement #1

Timeline: ~15 days before

What happensObjectives
Each release train prioritize the backlog based on their best current knowledge.

Features which have dependencies on other release train are annotated.

Each feature gets a driver, who facilitates the securing of “Definition of Ready”.
From our release trains perspective, a prioritised backlog candidate with know dependencies to other release train

Refinement #2

Timeline: ~5 days before

What happensObjectives
The release train backlog is prioritized.

The most important input is that it now has handshake priorities for features that have dependencies to other release trains.

Check that all features do indeed pass “Definition of Ready” for BRP.
All features with known dependencies across release trains now have an aligned (stack ranked) priority.

All features pass “Definition of Ready”

5 days before

What happens Objective
The backlog is ready for big room planning. It has been prioritized, and all features in it pass “Definition of Ready”.Teams can take a sneak peak at it from this point. Prepared backlog visible by teams

Who should be there?

There are three key roles that are mandated to be there. Additionally, based on context, this can be extended with, for example, Customers (yes!), Project Managers (if they have active features) or UX (“extended team”).

But let’s focus on the key roles and their responsibility:

Product ManagerOwns the refinement process. Makes sure it is run and that features are prepared in time for BRP
Responsible for Value
Prioritizes the Backlog
ArchitectFacilitates guestimation (“round sizing”) of features
Aligns architecture direction
Facilitates technical enablers in the Backlog
POResponsible for user experience
Slices features into sprints
Prioritize what the team takes on
Set balance of ”lights on” vs. feature work for his/her team (develops scenario)

BRP Definition of Ready

This is the million dollar question, finding “good enough” is key. A small note before we jump into a baseline solution: The appropriate level will vary with maturity. As you get better at this, and as teams take a higher degree of value responsibility, what is a process artifact will be made redundant by an uplift in skill, and through development/design tooling.

Baseline example

Has a problem statement ”why customers care”
Has an acceptance criterion “how would I demo it?”
Has a sketch of the user journey
Has an architecture sketch
Test environment changes expressed (if integration, system test environments need to be complemented to validate that the feature works)
Fits in an increment (6-8w)

And that should do it!

Give it a try, experiment and improve from there!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.