In this video, I explain what Synthesize is and how it works within the SAFe DevOps Health Radar. Synthesize is the fourth and final step of Continuous Exploration, where we combine the outputs of Hypothesize, Collaborate and Research, and Architect into a prioritized backlog with a clear vision and roadmap.
Creating a Clear Vision#
At this point in Continuous Exploration, we have a set of epics with hypothesis statements, identified customer needs, and a minimal architecture. What we lack is a clear vision of what we want to achieve. Synthesize fills that gap.
A vision needs to reflect both customer and stakeholder needs and should answer these questions:
- What will this new solution do?
- What problem will it solve?
- What are the features and benefits it will provide?
- For whom will it provide these features and benefits?
- What non-functional requirements will it deliver?
Breaking Epics into Features#
From the Hypothesize step, we have large epics that are significant initiatives lasting longer than three months. We now need to break these epics down into features and enabler features.
A feature fulfils a stakeholder need. An enabler feature paves the architectural runway so that we can deliver more business features in the future. Each feature consists of:
- A title
- A benefit hypothesis
- Acceptance criteria
- Non-functional requirements
A feature should always be bigger than a single sprint or iteration, but smaller than a quarter year or a Program Increment (PI). For example, a feature titled “In-Service Software Update” might have the benefit hypothesis “Significantly reduce the planned downtime,” with acceptance criteria such as automatic and manual updates, rollback capacity, and all enabled services running after the update.
Behaviour-Driven Development (BDD)#
One powerful way to define acceptance criteria is through Behaviour-Driven Development (BDD). Instead of writing acceptance criteria as plain sentences, BDD uses the Given-When-Then format:
- Given: The initial condition
- When: The action being performed
- Then: The expected result
This approach creates executable specifications. Traditional specifications in Jira, Word, or Confluence become outdated the moment you save them. The only truth for a specification lies within the code. BDD enables us to write tests directly from acceptance criteria, keeping our specification always in sync with the implementation.
Prioritizing with WSJF#
Once all features and enabler features are defined, they go into a program backlog. The critical question is: how do we prioritize them?
SAFe uses Weighted Shortest Job First (WSJF), a technique that maximizes economic benefit. The formula is:
WSJF = Cost of Delay / Job Size
Cost of Delay is the sum of three factors:
- User-Business Value: How much value does this feature deliver?
- Time Criticality: How urgent is this feature?
- Risk Reduction / Opportunity Enablement: Does this feature reduce risk or enable new opportunities?
For each factor, we compare all features and assign Fibonacci numbers (1, 2, 3, 5, 8, 13) relative to the feature with the lowest value. The feature with the highest WSJF gets the highest priority. This ensures we always work on items that deliver the most economic value in the shortest time.
Building the Roadmap#
With a clear vision and a prioritized backlog, we can now create a roadmap that defines the path to achieving our vision. Roadmaps exist at multiple levels:
- Daily: Very detailed, what we work on today
- Sprint/Iteration: Roughly two weeks of planned work
- Quarterly/PI: A three-month view with features and enablers
- Yearly: A broader strategic outlook
- Three-Year: A high-level directional plan
The roadmap is very detailed for today and the current sprint, and progressively less detailed as we look further into the future.
The Output of Synthesize#
The synthesize step produces three key outputs:
- A clear vision of what we are trying to achieve and which customer and stakeholder needs we want to fulfil
- A prioritized program backlog containing features and enabler features
- A roadmap showing how we plan to achieve the vision
With these outputs, we are ready to move into the next quarter of the SAFe DevOps Health Radar: Continuous Integration. Now we begin developing the features we have identified and prioritized.
The Maturity Levels#
- Sit: The program backlog does not exist or is not shared.
- Crawl: The program backlog exists, but features are incomplete and prioritization is an afterthought.
- Walk: The program backlog contains fully defined features, but they are not prioritized using WSJF.
- Run: Features in the program backlog are complete, prioritized using WSJF, and calibrated to the delivery capacity of an Agile Release Train (ART).
- Fly: The program backlog is a collection of Minimal Marketable Features (MMFs) created using Behaviour-Driven Development and prioritized using WSJF.
Key Takeaways#
- Vision first. Before building anything, create a clear vision that reflects customer and stakeholder needs and defines what problem you are solving, for whom, and what benefits you will deliver.
- Break epics into right-sized features. Features should be bigger than a sprint but smaller than a quarter. Each feature needs a benefit hypothesis, acceptance criteria, and non-functional requirements.
- Use BDD for executable specifications. Given-When-Then acceptance criteria keep your specification alive in code rather than outdated in documents.
- Prioritize economically with WSJF. Weighted Shortest Job First ensures your team works on the items that deliver the highest economic value relative to their size.
- Roadmaps at multiple levels. From daily plans to three-year outlooks, roadmaps provide clarity at every horizon while becoming progressively less detailed over time.
- Synthesize connects exploration to delivery. It transforms raw inputs from Hypothesize, Collaborate and Research, and Architect into actionable, prioritized features ready for Continuous Integration.