Quality begins with the intent.

—W. Edwards Deming

Solution Intent

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 being built?
  • How will it be built?

What’s more, these two questions are interrelated and have an impact on one another. If one doesn’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. 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 key to unlocking agility in large-scale solution development.

Details

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 [1] 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 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 Knowledge 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, Agile Teams, 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
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 full 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).

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 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. Contrast traditional and agile requirements

Solution intent serves as 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 (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 [2]. 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 shall always be as follows”)
  • Compliance standards (“comply with all PCI compliance 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

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

Collaboratively Develop the Solution Intent

Solution intent is a collaborative effort between teams and program leadership. Product and Solution Management, along with a System and Solution Architects/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.

Figure 4. Solution Intent evolves through collaboration
Figure 4. Solution Intent evolves through collaboration

Solution intent drives the solution Roadmap and ultimately backlog items to execute. 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 and Releases that 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 do reduce uncertainty through 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 of Build-Measure-Learn and Pivot or Persevere still apply.

Connect Solution Intents across the Supply Chain

At scale, the solution intent does not necessarily stand alone. Since the system is composed of multiple subsystems, the solution intent often spans those subsystems, including suppliers. Suppliers will 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. Solution Intent hierarchy

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 [5]. 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 to 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 values instead of fixed numbers to enable Set-Based Design. 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 with compliance and contractual obligations. Less is more.

Learn More

[1] Manifesto for Software Development. AgileManifesto.org

[2] Ward, Allen, and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[3] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

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

[5] Ambler, Scott. Agile Architecture: Strategies for Scaling Agile Development. Agile Modeling, 2012. http://agilemodeling.com/essays/agileArchitecture.htm

 

Last update: 12 October 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.