Solution Intent in SAFe Explained

0:00 Agile vs documentation: the problem

Hi, my name is Vicky from mozek dot academy. Agile teams value working software over comprehensive documentation. But what if a failure would be very costly, in a medical device, or a banking platform? Then you need both. SAFe's answer to this dilemma is called Solution Intent. Let's explore what Solution Intent is and where it fits in the SAFe ecosystem. We'll also look at who creates it, who contributes to it, and who relies on it.

The Agile Manifesto puts it plainly: we value working software over comprehensive documentation. But SAFe points out that enterprises building complex systems often need both. First, what does SAFe mean by a solution?

0:41 What is a solution in SAFe?

It's a product, a system or a service that provides value to customers, and those customers can be internal or external. An Agile Release Train develops and delivers one or more solutions, and often operates them too. When a solution is too large for one train, a Solution Train coordinates several Agile Release Trains and suppliers to build it. Take a bank, for example. Its new mortgage platform is a solution for home buyers, and the fraud-monitoring tool its own analysts use is a solution too.

In SAFe, Solution Intent is the repository where you store, manage and communicate what you know about the solution.

1:15 Solution Intent defined

That covers how it behaves and is designed today, and how it's meant to behave and be designed in the future. Where it's needed, it holds fixed and variable specifications and designs, references to the standards that apply, system models, and functional and nonfunctional tests. It also supports traceability. It exists because large systems need everyone to agree on two questions.

1:40 The two questions Solution Intent answers

What exactly are we building? And how will we build it? The two questions are linked, because if there's no feasible way to build something, you have to rethink what you're building. So where does Solution Intent fit?

1:56 Where Solution Intent fits in SAFe

Here's a simplified view of SAFe's Large Solution configuration. The Solution Train is at the top, the Agile Release Trains are below it, and the agile teams are at the base. Each level has its own roles. Solution Intent sits at the Large Solution level, right next to compliance, model-based systems engineering and set-based design. But generally, any SAFe element can be used in any configuration, so even a single train building a regulated product may need a Solution Intent.

So what goes into Solution Intent?

2:28 What goes into Solution Intent

First of all, it holds the requirements, such as capabilities, features, stories and nonfunctional requirements. It holds the design as well, including the architecture, models, interfaces and customer specifications, and it keeps the tests together with their results. It also captures the reasoning behind decisions, like trade studies, experiment results and the reasons a particular design was chosen. Quite often, all of this has to become part of the official record.

SAFe organizes that knowledge in two ways. The first is over time, separating what the system does now from what's intended for the future. The second is by type, splitting it into specifications, design and tests. Traceability connects all of these to each other and to the parts of the system that implement them, and that helps you confirm that a critical system will behave as intended. The form is up to you: it can live in documents, spreadsheets, whiteboards or modeling tools.

Now we get to the most important idea.

3:27 Fixed vs variable Solution Intent

Fixed intent is what's already known. Some of it is non-negotiable from the start, and some of it is decided along the way. Variable intent is still open, and teams explore the alternatives to find the best economic trade-off. SAFe deliberately lets that variability continue, even late in the timeline. Enablers are how teams explore the unknowns, and set-based design keeps several options alive until the best one becomes clear.

The teams record their findings in Solution Intent, and that's how variable intent becomes fixed. So in every PI, teams build what they know while they explore what they don't know yet. Let's go back to the bank.

4:07 Example: a bank's mortgage platform

Its mortgage platform is a large solution, built by several trains together with an outside supplier for identity checks. Some of its intent is fixed from day one. Banks must verify each customer's identity and screen for money laundering, and the platform has to work with today's core banking system. Other intent is variable. Should the platform check income from uploaded payslips, or, with the customer's consent, from their bank account data?

Teams explore both options, and the choice becomes fixed once they've learned which one works best. Even the time to a decision can start out as a range rather than a single number.

4:46 Up-front requirements vs Lean-Agile

That's a big change from the traditional approach, where senior engineers worked out the requirements in detail early on and then handed them off, which left little room to learn. In SAFe, requirements are detailed at the right time, by the people doing the work, through features, stories and conversations. That's why Solution Intent is never a one-time document. It keeps evolving. So who creates Solution Intent? It's a collaborative effort.

5:09 Who contributes to Solution Intent

Product Management and Solution Management, working with System Architects and Solution Architects, make the highest-level, system-wide decisions. They decide how the system is broken down, what its interfaces are, and which requirements go to which subsystems. They also set up how Solution Intent is organized, so that it supports later analysis and compliance. Suppliers often keep their own requirements and designs for the part they deliver.

From their point of view, that's their Solution Intent, and the top-level Solution Intent brings all the relevant information together. But there's no monopoly on innovation. Many team members help create Solution Intent, give feedback on it and refine it, so the exchange runs both ways. From the top come the economic framework, guidance and constraints. And from the teams come new knowledge, key decisions, issue resolution and new ideas.

And who relies on Solution Intent?

6:07 Who relies on it: roadmaps and backlogs

It drives the solution roadmap, and ultimately it determines which backlog items get built. Teams also use it to guide the decisions in their own backlogs. It's the single source of truth about how the solution is meant to behave and how it actually behaves. It aligns the customer, the agile teams and the suppliers around a common mission. And it helps an organization demonstrate compliance and meet its contractual obligations.

Back at the bank, an auditor asks how the platform makes sure that every applicant is screened.

6:35 Example: tracing an auditor's question

Traceability in Solution Intent leads from that requirement to the design that implements it, and from there to the tests that show it works. One word of warning: more documentation isn't automatically better.

6:49 Minimal but sufficient documentation

Solution Intent is a means to an end, and capturing it shouldn't create unnecessary overhead. SAFe recommends a handful of practices. Favor models over documents, and keep the work collaborative. Keep your options open for as long as that's economically feasible. Record each requirement and design decision in only one place. And stay high level and keep it simple, using ranges instead of fixed numbers and recording only what's needed.

Let's recap.

7:20 Recap

A solution is a product, system or service that delivers value. Solution Intent is one shared repository for what you're building, and how you'll build it. It holds fixed and variable intent, and variable intent becomes fixed as teams learn. Management and architects shape it, while teams and suppliers contribute to it. And it stays lean, with just enough to decide, align and demonstrate compliance. Thanks for watching.

For more short explainers like this one, please subscribe, and visit mozek dot academy.