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 documented, 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 is one of the most complex and challenging endeavors in industry today. System builders must continuously align 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 intertwined. If system builders don’t know how to develop the ‘what’ in an economical or in a technically feasible manner, they may need to revisit the ‘what’ 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.
System builders also recognize that some system understanding is fixed, with nonnegotiable 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 results.
Engineering complex and highly reliable solutions requires and creates 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 (ex., electrical and mechanical), interfaces, customer specifications, tests and test results, traceability, etc. Other relevant information records some of the key decisions and findings about the system. This may include information from trade studies, results of experiments, the rationale for design choices, and other items. In many cases, this information must become part of the official record, whether by necessity or regulation.
Solution Intent Aligns System Builders and Assures the System
Solution intent is a critical knowledge repository to store, manage, and communicate what system builders are building and how they’re going to build it. 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, the system builders, and Suppliers to a common purpose
- Supports Compliance and contractual obligations
Figure 1 illustrates the complex nature of solution intent:
- Current and future states – Builders 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 to the solution builder—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 confirms 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 built 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
System builders use solution intent for 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 system builders to explore 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, system builders reuse elements from developing systems previously. 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 are 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 system builders with 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 builders, 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—a tool to guide system builders, 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