Quality begins with the intent.

—W. Edwards Deming, Out of the Crisis [1]

Solution Intent

Definition: Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended solution behavior and design.

Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, functional and nonfunctional tests; and support for traceability.

The reason for solution intent is obvious. Building large-scale software and cyber-physical systems is 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 going to build?
How will we build it?

What’s more, these two questions are interrelated. If one doesn’t know ‘how’ to build something in an economically or technically feasible way, then ‘what’ is being built must be reconsidered. SAFe labels this critical knowledge pool Solution Intent. It provides a 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. Some solution intent 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 vital to unlocking agility in large-scale solution development.

Details

When building systems with a high potential cost of failure, the need for a more rigorous definition and validation of system behavior can be a significant barrier to Agile adoption. Although many practitioners resonate with the Agile Manifesto [2] 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 solution requirements and design—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 critical 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 System Knowledge in Solution Intent

Solution intent is a critical knowledge repository to store, manage, and communicate ‘what is being built’ and, where necessary, ‘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, Agile Teams, and Suppliers to a common mission and purpose
Supports Compliance and contractual obligations

Capture Both Current and Future 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

Figure 1. Anatomy of Solution Intent

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 complete behavior. The solution intent itself is created collaboratively and evolves based on learning.

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).

Solution Intent is Dynamic

Traditionally, a set of detailed, up-front, fixed requirements served to define the system. 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 throughout development.

Solution intent is not a static, one-time statement: it must support the entire development process and evolve. Figure 2 contrasts a traditional early, fixed requirements decomposition with a Lean-Agile approach where requirements are detailed by Features, Stories, and ultimately a face-to-face conversation.

Figure 2. Contrasting traditional and Agile requirements approaches

Solution intent carries with it a vision of the future system that aligns 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 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 [3]. 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 non-negotiable, or they may have emerged during development. Examples include:

Certain performance specifications (“the pacemaker waveform shall always be as follows”)
Compliance standards (“comply with all PCI credit card requirements”)
Core capabilities defining the solution (“the autonomous delivery vehicle’s maximum cargo weight is 450 US pounds”)

Variable intent represents the elements that enable teams to explore the economic trade-offs of requirements and design alternatives that could meet a broader need. Once established, these new insights will eventually become fixed requirements and design decisions.

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 the development of downstream features in the Roadmap (Figure 3).

Figure 3. Moving from variable to fixed solution intent over time

At each PI, teams are simultaneously building what they know while exploring what they don’t yet know.

Collaboratively Develop Solution Intent

Creating and evolving the solution intent is a collaborative effort. Product and Solution Management, along with System and Solution Architects, 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.

Figure 4. Solution Intent evolves through collaboration

Solution intent drives the solution roadmap and ultimately determines backlog items to execute. Solution intent begins with a vision describing the solution’s purpose and critical 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. Both the roadmap and solution intent are filled with assumptions and must adapt to knowledge gained from execution (Figure 5). This form of collaboration replaces the traditional approach that strives to reduce uncertainty through centralized and detailed specifications and plans.

Figure 5. Developing Solution Intent

SAFe’s guidance for continuous delivery validates assumptions through Minimum Viable Products (MVPs) that provide validated learning through frequent, quantifiable experiments. The validated learning in solution intent is predominately technical, but the business-focused Lean Startup principles still apply.

Connect Solution Intents across the Supply Chain

At scale, the solution intent does not stand alone. Since the system is composed of multiple subsystems, the solution intent often spans those subsystems, including information needed by suppliers. Suppliers will also often have separate and independent requirements, designs, and other specifications for their subsystem or capability. From their perspective, that is their solution intent. The ultimate (top-level) solution intent must include all relevant information across the subsystem hierarchy to communicate decisions, facilitate exploration, align teams, and support compliance (Figure 6).

Figure 6. The requirements and design hierarchy of Solution Intent

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. The Lean-Agile community recommends keeping it ‘light’ when documenting requirements, design, and architecture [4]. Best practices include:

Favoring models over documents – An environment of continuous change challenges a document-centric approach to organizing and managing solution intent. Models (including those produced by modern practices such as design thinking and user-centered design) can provide easier ways to manage the information, as is further discussed in MBSE.
Keeping solution intent collaborative – There is ‘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 creating, providing feedback, and refining 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 it is economically feasible. Set-based design practices help to avoid committing to design and requirements too early.
Documenting items in only one place – Record needed 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. Enable Set-Based Design by providing a range of acceptable values instead of fixed numbers. Describe solution behavior with intent, not specificity. Decentralize requirements and design decision-making authority.
Keeping it simple – Solution intent is a method for building a product with compliance and contractual obligations. Record only what’s needed.

Learn More

[1] Deming, W. Edwards. Out of the Crisis. The MIT Press, 2018.

[2] Manifesto for Agile Software Development. http://AgileManifesto.org/

[3] Ward, Allen C., and Durward K. Sobek II. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[4] Ambler, Scott. Agile Architecture: Strategies for Scaling Agile Development. Agile Modeling, 2012. Retrieved September 21, 2023, from http://agilemodeling.com/essays/agileArchitecture.htm

Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use Case Approach. Addison-Wesley Professional, 2003.

Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 9 October 2023