Quality begins with the intent.
—W. Edwards Deming
Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, and functional and nonfunctional tests; and traceability.
Building large-scale software and cyber-physical systems are one of the most complex and challenging endeavors in the industry today. This requires alignment on two central questions:
- What exactly is this thing we are building?
- How are we going to build it?
What’s more, these two questions are interrelated and have an impact on one another. If you don’t know ‘how’ to build something in an economically or technically feasible way, then ‘what’ is being built must be reconsidered in the context of the ‘how.” SAFe labels this critical knowledge pool the solution intent—the basic understanding of the current and evolving requirements, design, and intent—that is, the larger purpose of the solution.
Some solution intent is fixed, with non-negotiable requirements for what it must do or already does. And some is variable, subject to further discussion and exploration as facts surface. Understanding and navigating these differences, and allowing variability to proceed (even late into the timeline), are key to unlocking agility in large-scale solution development.
When building systems that have an unacceptably high cost of failure, the need for a more rigorous definition and validation of system behavior is a significant barrier to Agile adoption. Although many practitioners resonate with the Agile Manifesto  value statement of “working software over comprehensive documentation,” that concept can generate conflicting priorities for enterprises that need both.
Engineering complex and highly reliable solutions require and create large amounts of technical information. Much of it reflects the intended behavior of the solution—Features and Capabilities, Stories, Nonfunctional Requirements (NFRs), system architecture, domain-level models and designs (e.g. electrical and mechanical), system interfaces, customer specifications, tests and test results, and traceability. Other relevant information records some of the key decisions and findings of the system. This may include information from trade studies, results of experiments, the reasoning for design choices, and other items. In many cases, this information must become part of the official record, whether by necessity or regulation.
Capture Knowlege in Solution Intent
Solution intent is a critical knowledge repository to store, manage, and communicate ‘what is being built’ and ‘how it will be built.’ It serves many purposes:
- Provides a single source of truth regarding the intended and actual behavior of the solution
- Records and communicates requirements, design, and system architecture decisions
- Facilitates further exploration and analysis activities
- Aligns the Customer, Dev Team, and Suppliers to a common mission and purpose
- Supports Compliance and contractual obligations
Future and Current Solution Intent
Figure 1 illustrates the complex nature of solution intent:
- Current and future states – Developers of complex systems must constantly know two things: what exactly the current system does now, and what changes are intended for a future state
- Specifications, designs, and tests – Knowledge of both the current and future states can be captured in any form suitable—as long as it includes the three primary elements: specifications (documented definition of system behavior), design, and tests
When building systems that must behave exactly as intended—including life-critical, mission-critical, and others governed by regulatory standards—traceability helps confirm that the system will behave as intended. It connects the elements of solution intent to each other and to the components of the systems realizing its full behavior. The solution intent itself is created collaboratively and evolves based on learning, as illustrated in Figure 1.
The specific elements of solution intent can be realized in many forms: from documents, spreadsheets, and whiteboard sessions to formal requirements and modeling tools, as described in Model-Based Systems Engineering (MBSE). But solution intent is a means to the end of building the solution, so methods for capturing it should not create unnecessary overhead and waste (see the sufficiency discussion below).
Make the Solution Intent Dynamic
Traditionally, a set of detailed, up-front, fixed requirements served as the proxy for the solution intent. But SAFe Principle #3, Assume variability; preserve options, tells us that defining requirements and designs too tightly up-front leads to less successful outcomes. A different approach is needed, one that supports understanding what’s known, yet allows what’s unknown to emerge over the course of development.
The solution intent is not a static, one-time statement: it must support the entire development process and continue to evolve. Figure 2 contrasts the traditional early, fixed requirements decomposition with a Lean-Agile approach, where decomposition is done at the appropriate time by the people doing the work.
Solution intent serves as a vision of the future system that aligns these teams and their backlogs. It provides the detail needed to establish the current vision but allows teams the flexibility to explore unknowns in building the solution. The resulting knowledge (Can we build the future system, and what did we learn from exploration?) provides feedback on the to-be system and the opportunity to adapt.
Keep Options Open with Fixed and Variable Solution Intent
Solution intent serves a variety of purposes. However, none of them mandates creating fully defined ‘point-solution’ specifications up-front. Such early decisions restrict the exploration of better economic alternatives and often lead to waste and rework.  To prevent this, SAFe describes two elements of solution intent, fixed and variable, that support the general adaptive requirements and design philosophy that create the best economic outcome.
Fixed intent represents the ‘knowns.’ They may be nonnegotiable, or they may have emerged during the course of development. Examples include:
- Certain performance specifications (“the pacemaker waveform must be as follows”)
- Compliance standards (“comply with all PCI compliance credit card requirements”)
- Core capabilities defining the solution (“the Baja Adventure Ride holds four adult riders”)
Variable intent represents the elements that allow the exploration of the economic trade-offs of requirements and design alternatives that could meet the need. Once established, these new insights will eventually become fixed requirements.
Moving from variable to fixed requires gaining knowledge to make decisions. Enablers are SAFe’s vehicle to explore unknowns and record knowledge and decisions in the solution intent. Following Set-Based Design practices, teams explore alternatives to arrive at an optimal economic decision. These decisions enable development of downstream features in the Roadmap (Figure 3).
At each Program Increment (PI), teams are simultaneously building what we know, while exploring what we don’t yet know.
Fixed knowledge doesn’t start off at zero because even at the left end of Figure 3, a lot is known. For example, the reuse of elements from previously developed systems. Then, through the course of development, more becomes known as fast as Iterations, PIs, and Solution Demos show what the system is capable of. In this way, variable intent becomes fixed over time and a solid understanding of what the system does and needs to do emerges.
Collaboratively Develop the Solution Intent
Solution intent is a collaborative effort between teams and program leadership. Product and Solution Management, along with a Solution Architect and Systems Engineering, are responsible for the highest-level, system-wide decisions (system decomposition, interfaces, and allocations of requirements to various subsystems and capabilities). They also establish the solution intent’s organizational structure to support future analysis and compliance needs. Solution intent helps drive localized decisions in the teams’ backlogs, as shown in Figure 4.
The resulting work provides feedback to program leadership on the progress and direction.
As shown in Figure 5, backlog items define the work that populates the solution intent, moving the variable assumptions toward fixed decisions.
Solution intent begins with a Vision that describes the solution’s purpose and key capabilities, along with the system’s nonfunctional requirements. This knowledge and the emerging roadmap and critical Milestones guide teams in creating backlogs and planning their work. But the roadmap and solution intent is filled with assumptions. SAFe’s guidance for continuous delivery validates assumptions through Minimum Viable Products (MVPs) that provide validated learning through frequent, quantifiable experiments. Note: The validated learning in solution intent is predominately technical, but the Lean Startup principles of Leap-Test-Measure-Pivot still apply.
Connect Solution Intents across the Supply Chain
A system’s solution intent does not necessarily stand alone. Many solutions are systems that participate in a higher-level system of systems. In that case, other systems, as well as suppliers, provide unique knowledge and solution elements that accelerate development. Suppliers, for example, will often have separate and independent requirements, designs, and other specifications for their subsystem or capability. From their perspective, that is their solution intent. As a result, the ultimate (top-level) solution intent must include the relevant supplier knowledge and information necessary to communicate decisions, facilitate exploration, align teams, and support compliance. This ‘daisy chain’ of requirements moves design decisions up and down the system hierarchy, as illustrated in Figure 6.
Create Minimal but Sufficient Documentation
Solution intent is a means to an end—it’s a tool to guide, facilitate and communicate decisions, and demonstrate compliance. Planning the solution intent’s content, organization, and documentation strategies should begin with those ends in mind. But more is not necessarily better. When documenting requirements, design, and architecture, the Lean-Agile community recommends keeping it light . Best practices include:
- Favoring models over documents – An environment of continuous change challenges a document-centric approach to organizing and managing solution intent. When applied properly, models (including those produced by modern practices such as design thinking and user-centered design) can provide more easily maintained ways to manage, as is further discussed in MBSE.
- Keeping solution intent collaborative – There’s no monopoly on innovation, and solution intent is not the exclusive domain of the Product and Solution Managers, Architects, and Engineers. Many team members participate in the creation, feedback, and refinement of solution intent information.
- Keeping options open – Defer decisions to local concerns, and make them as late as possible. An adaptive approach to requirements and design keeps promising options open as long as is economically feasible. Set-based design practices help avoid committing to design and requirements too early.
- Documenting items in only one place – Record any requirements and design decisions in one place, a single source of truth that serves as the repository of record for everyone and everything.
- Keeping it high level – Communicate at as high a level of abstraction as possible, and don’t over-specify. Provide a range of acceptable behaviors. Describe solution behavior with intent, not specificity. Decentralize requirements and design decision-making authority.
- Keeping it simple – Record only what’s needed. Solution intent is a method for building a product while compliance and contractual obligations. Less is more.
Learn More Agilemanifesto.org.  Ward, Allen and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.  Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.  Leffingwell, Dean and Don Widrig. Managing Software Requirements: A Use Case Approach. Addison-Wesley, 2003.  Ambler, Scott. “Agile Architecture: Strategies for Scaling Agile Development.” Agile Modeling, 2012. http://agilemodeling.com/essays/agileArchitecture.htm.
Last update: 5 October, 2017