SAFe® is Analysis: Translating the Terminology

SAFe® (the Scaled Agile Framework) is all about business analysis but it never uses the word “analysis” or has any role for analysts. This blog post offers a translation guide of SAFe terms into their corresponding analysis terms. (Skip to Guide)

A Little History

Agile software development has been promoted as the answer to IT development backlogs and delays for over a decade and has proven to be useful in creating software products for many organizations. But as many teams and organizations have tried to “become more agile”, most have had only limited success.  Many manufacturing, healthcare, and financial services companies are continuing to struggle, not getting the benefits expected from this adaptive, change-driven approach to design and development. As a business analyst, I have always been frustrated by the lack of attention to business analysis in agile. The creators of agile discounted (or completely forgot about!) the value of business analysis when agile approaches were originally defined. Development professionals felt a development team working directly with a business product owner could create useful products. (I’ll leave the discussion of why this doesn’t work to another article.)

SAFe®: The Scaled Agile Framework

After ten years of trying to make agile work, what had to be learned, as it did with traditional waterfall approaches, is that analyzing business needs and considering alternative solutions before coding is not only valuable, but essential to the success of a software development effort. Now agile enterprise frameworks like SAFe® have been created to fill the analysis gap in the original agile approaches.

SAFe offers a structured, top down approach to strategic analysis, prioritization, and assignment of work to agile development teams. Unfortunately, the creators of SAFe invented new terminology and new roles to describe strategic and multilevel analysis rather than using industry standard analysis language –  IIBA®’s BABOK® Guide (International Institute of Business Analysis; A Guide to Business Analysis Body of Knowledge.

SAFe attempts to describe a step by step recipe for business analysis starting with a high level strategic plan (using epics and strategic themes), decomposing business capabilities, identifying technical architecture needs, prioritizing and then building software. I am impressed that the creators of SAFe would attempt to define a methodology (although they would never use this word) for a very complex, multilayered and ever-changing process. When IIBA’s BABOK Guide coined the phrase Enterprise Analysis in 2004 it took several years before people began to understand what we meant and began to use the phrase to describe high level analysis which must be done before beginning work on individual projects.

SAFe Terminology

SAFe terminology is built around a train analogy. There are Solution Train Engineers and Release Train Engineers and the ART is the Agile Release Train (a team of Agile teams). According to the Scaled Agile Framework, the trains carry the features through the process and if a feature misses one train it can catch the next one. The train analogy doesn’t carry all the way through because there are also roadmaps and runways.

It’s a Foreign Language!

To describe how SAFe uses organizational goals to drive product development work (and who should be involved) SAFe uses new processes and roles (you’ll recognize some terms from Lean). The SAFe transformation roadmap recommends training everyone in your organization to learn this new, foreign language of release trains and epics.  This is one way of trying to transform an organization – require it to work in a different language with different processes. I like the focus on analysis from a high level in the organization, tracing down to individual development teams but am not sure about the foreign language.  Why do we need a new set of terms?

A Translation Guide

The tables below are not intended to teach SAFe but rather to help translate the language. I have found it useful to align SAFe terminology with words and phrases known in the BABOK Guide. The human brain learns new information by attaching it to something we already know. Linking SAFe terms to existing analysis knowledge may help with learning.

Roles Translation
SAFe Roles
Traditional Roles
Lean Portfolio Managers Executives who drive strategy, investment funding and prioritization
Epic Owner


Project sponsor. Person who funds and champions the creation of a solution.
Solution Train Engineer (STE) IT Director or Manager. Oversees large development efforts with multiple release trains.
Solution Train, Release Train (RT), Agile Release Train (ART) Development teams working on different components of a solution.
Release Train Engineer (RTE) (acts as Chief Scrum Master for the Train) Project manager, Business analyst, or Facilitator
Product Manager (PM) Business domain SME responsible for product marketing and product strategy.
Product Owner (PO) Business domain SME embedded with a team; responsible for prioritizing product features, managing product backlog, establishing acceptance criteria. PO reports to Product Manager. Some organizations use business analysts who are domain experts in this role.
Product Owner proxy Requirements or business analyst who represents the PO on a remote team
Business owners Business domain SMEs, stakeholders
System architect-engineer Systems analyst, systems architect, enterprise architect
Team Scrummaster Project manager or delivery manager


Terminology Translation


SAFe Terminology
BABOK Guide Terminology
Framework Methodology or Process
Epic, Capability High level business need or requirement
Epic roadmap and Strategic themes Strategic plan, Strategy analysis, Enterprise analysis, High level business objectives
Business Case/Financial Justifications
Lean business case (for an epic) Business case
Outcomes hypothesis, continuous value Expected benefits, business value
Epic outcome hypothesis statement Statement describing the desired functionality, expected value, measurable results and nonfunctional requirements.
Opportunity enablement (OE) New business opportunity value
Economic framework Cost benefit analysis
Non-economic based prioritization Prioritization based on intangible benefits
Lean budgets Budgeting based on value streams rather than projects
Analysis Techniques
Research resources and methods, continuous exploration Elicitation techniques
GEMBA walk (Japanese concept of going to the real place) Observation or job shadowing
Feature decomposition Functional decomposition
Feature decomposition patterns: (e.g. workflow, business rules, data methods, use case scenarios) Decomposition methods (e.g. bottom up, top down, data driven, sequential)
Continuous exploration, Collaboration and research synthesis Requirements analysis and design
Program Increment Planning (PIP) –
A 2-3 day face to face workshop to get agreement on vision, scope, requirements, priorities, design, and development plans using techniques like clear problem definition, root cause analysis, Pareto analysis, brainstorming, dot voting.
  • Project kickoff
  • Scoping workshop
  • Requirements workshop


Model Based Systems Engineering (MBSE)
  • Requirements modeling
  • Business modeling
  • Data and process modeling
Solution context or Product vision
  • Context diagram
  • Solution or Product scope
  • Future state
Alignment (epics should drive backlog items) Traceability
Weighted Shortest Job First (WSJF) shorter duration and higher cost to delay Quick wins
Set-based design Considering alternative solutions during design
  • Architecture runway
  • Enabler (build up the runway or extend the runway)
Technical requirements for code, databases, hardware components, or infrastructure that are needed for the development of business features
Program Increment (PI) A solution or part of a solution that supports a business program.
Program Increment (PI) Roadmap
  • Product or solution roadmap
  • Release plan with release dates
  • Project schedule
  • Phased implementation plan
Program Increment (PI) Objectives


SMART (specific, measurable, achievable, realistic, time framed) Objectives
Continuous delivery pipeline

  • Continuous exploration
  • Continuous integration
  • Continuous deployment
Emergent design Solution design resulting from collaboration
  • Portfolio
  • Program
  • Team
Types of backlog
  • Solution Intent
  • User Stories
  • Enabler stories
  • Improvement stories


  • Business objectives and requirements
  • Solution Requirements
  • Functional Requirements
Features (decomposed from Epics, capabilities or enablers)
  • Backlog items with business priority
  • Stakeholder requirements
Risk reduction (RR) Risk mitigation
ART Sync meeting (SCRUM of SCRUMS and Product Owner Sync) Weekly meeting of PMs to share progress on related projects
Capacity Allocation
  • Percentage of time allocated to the project work by a resource
  • Project scheduling
Release on demand Deployment as scheduled by business (versus regularly scheduled releases)
Learning cycles, cadence Sprints or iterations with retrospectives
Big up front design (BUFD) Waterfall approaches
Portfolio Kanban Portfolio or program management


Common Terminology (there are a few existing terms used by SAFe)

  • Solution
  • Go/No go
  • Nonfunctional Requirements
  • Capability
  • Portfolio, Program levels
  • Team


Missing Concepts/Terms (there are a few key analysis concepts missing from SAFe)

  • Current state analysis
  • Data analysis and modeling
  • Glossary
  • Interface analysis
  • Requirements reuse
  • Post implementation assessment
Learn the Language

SAFe lays out a process for enterprise analysis which is thorough and will result in opportunities for deep analysis at both the enterprise and product levels. It includes many great analysis techniques, most of which have been successfully used for years by business analysis professionals. I hope organizations which embrace SAFe are successful in transforming their businesses, but I fear this is another methodology, like RUP (the Rational Unified Process) which will flame brightly and then die because it focuses too heavily on new language while failing to grasp the complexity of analysis and the need for professionals who are experts in helping organizations think about their true business needs. For now, business analysts and project managers must learn this new language and adapt their existing practices to operate in this new environment (until the next silver bullet comes along!).

If you would like a copy of this blog post in a PDF format, send me an email message at or post a reply here.

5 thoughts on “SAFe® is Analysis: Translating the Terminology”

  1. Great article Barbara; this is solid thought leadership material. I love the mapping and yes please send me a PDF copy.

    Your comment about the BABOK from the IIBA being the industry standard analysis language makes me think. I think that we in the BA profession self-declared the BABOK to be an industry standard but that in and of itself does not necessarily lead to concurrence from other professions. I suspect the PMI-BA folks would claim their material serves to function as the “industry standard”. I believe that other professions such as the OMG claim their material is the book of record.

    Regardless, the analysis you shared is terrific and a goldmine for the BA practitioner struggling to speak to Agile practitioners in their language.

  2. Barb – thanks for taking the time to translate the SAFe language into meaningful chunks that
    BAs can digest. This is a super helpful resource and it shows the value that Business Analysis brings to the organization.

Leave a Reply

Your email address will not be published. Required fields are marked *