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”.
Scenario
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 happens | Objectives |
| 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 happens | Objectives |
| 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:
| Role | Responsibility |
| Product Manager | Owns the refinement process. Makes sure it is run and that features are prepared in time for BRP Responsible for Value Prioritizes the Backlog |
| Architect | Facilitates guestimation (“round sizing”) of features Aligns architecture direction Facilitates technical enablers in the Backlog |
| PO | Responsible 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!
