safe epic hypothesis statement example

The SAFe® Epic – an example

We often have questions about what a “good” sufficiently developed SAFe Epic looks like. In this example we use with clients during the Lean Portfolio Management learning journey, we dive into an example of real-world details behind an epic hypothesis statement.

For now, we have not provided a fully developed SAFe Lean Business Case as an example because business cases are typically highly contextual to the business or mission. That being said please remember that the core of the business case is established and driven from the Epic Hypothesis Statement and carried over into the documented business case.

Agile Lifecycle Management Solution Enabler Epic

Epic Owner: John Q. Smith

Epic Description

The big awesome product company requires a common platform for collaboration on work of all types across the portfolio for all teams, managers, architects, directors, and executives including customer collaboration and feedback loops. This solution will solve the problems in our system where we have poor quality or non-existent measurement and multiple disparate systems to manage and report on work.

For the Portfolio Teams

Who needs to manage their work, flow, and feedback

The single-source system of record for all work

IS A web-based software tool suite that provides customizable workflows that support the enterprise strategic themes related to creating better business and IT outcomes using guidance from the Scaled Agile Framework for Lean Enterprises (SAFe), Technology Business Management (TBM), and Value Stream Management (VSM) via the Flow Framework

THAT will provide a common place for all customers and portfolio stakeholders to have a transparent vision into all of the work occurring in the system/portfolio, provide a mechanism to manage capacity at scale, and enable easier concurrent road mapping  

UNLIKE the current array of disparate, ad hoc tools and platforms

OUR SOLUTION will organize all work in a holistic, transparent, visible manner using a common enterprise backlog model combined with an additive enterprise agile scaling framework as guidance including DevOps, Lean+Systems Thinking, and Agile

Business Outcomes:

• Validate that the solution provides easy access to data and/or analytics, and charts for the six flow metrics: distribution, time, velocity, load, efficiency, and predictability for product/solution features (our work). (binary)
• The solution also provides flow metrics for Lean-Agile Teams stories and backlog items. (binary)
• 90% of teams are using the solution to manage 100% of their work and effort within the first year post implementation
• All features and their lead, cycle, and process times (for the continuous delivery pipeline) are transparent. Feature lead and cycle times for all value streams using the system are visible. (binary)
• Lean flow measurements — Lead and cycle times, six SAFe flow metrics, and DevOps metrics enabled in the continuous delivery pipeline integrated across the entire solution platform (binary)
• Activity ratios for workflow, processes, and steps are automatically calculated (binary)
• Percent complete and accurate (%C&A) measures for value streams automatically calculated or easily accessible data (binary)
• Number of documented improvements implemented in the system by teams using data/information sourced from the ALM solution > 25 in the first six months post implementation
• Number of documented improvements implemented in the system by teams using data/information sourced from the ALM solution > 100 in the first year post implementation
• Flow time metrics improve from baseline by 10% in the first year post implementation (lead time for features)
• Portfolio, Solution/Capability, and Program Roadmaps can be generated by Lean Portfolio Management (LPM), Solution Management, and Product Management at will from real-time data in the ALM (binary)
• Roadmaps will be available online for general stakeholder consumption (transparency)
• Increase customer NPS for forecasting and communication of solution progress and transparency of execution by 20% in the first year post implementation (survey + baseline)
• Build a taxonomy for all work including a service catalog (binary)
• Run the system and the system produces the data to produce the capacity metrics for all value streams to enable the LPM guardrail (binary)
• Stops obfuscation of work hidden in the noise of the one sized fits all backlog model (everything is a CRQ/Ticket) and allows for more accurate and representative prioritization including the application of an economic decision-making framework using a taxonomy for work (binary)
• Enables full truth in reporting and transparency of actual flow to everyone, real-time – including customers (100% of work is recorded in the system of record)
• Enables live telemetry of progress towards objectives sourced through all backlogs, roadmaps, and flow data and information (dependent)
• 90% of teams are using the solution to manage 100% of their capacity within the first year post implementation

Leading Indicators:

• Total value stream team member utilization > 95% daily vs. weekly vs. per PI
• Low daily utilization < 75% indicates there is a problem with the solution, training, or something else to explore
• % of teams using the ALM solution to manage 100% of their work and effort
• Number of changes in the [old solutions] data from the implementation start date
• Usage metrics for the [old solutions]
• We can see kanban systems and working agreements for workflow state entry and exit criteria in use in the system records
• Teams have a velocity metric that they use solely for the use of planning an iterations available capacity and not for measuring team performance (only useful for planning efficiency performance)
• Teams use velocity and flow metrics to make improvements to their system and flow (# of improvements acted from solution usage)
• Teams are able to measure the flow of items per cycle (sprint/iteration) and per effort/value (story points; additive)
• Program(s)[ARTs] are able to measure the flow of features per cycle (PI) and per effort/value (story points; additive from child elements)
• Portfolio(s) are able to measure the flow of epics per cycle (PI) and per effort/value (story points; additive from child elements)
• % of total work activity and effort in the portfolio visible in the solution
• Show the six flow metrics
• Features (Program) – current PI and two PI’s into the future
• Epics and Capabilities – current PI up to two+ years into the future
• are the things we said we were going to work on and what we actually worked on in relation to objectives and priorities (not just raw outputs of flow) the same?
• The portfolio has a reasonable and rationalized, quality understanding of how much capacity exists across current and future cycles (PI) in alignment with the roadmap
• Identification and reporting of capacity across Portfolio is accurate and predictable;
• Identification of Operational/Maintenance-to-Enhancement work ratio and work activity ratios and % complete and accurate (%C&A) data readily available in the system
• including operations and maintenance (O&M) work and enhancements,
• highlighting categories/types of work
• Work activity ratios are in alignment with process strategy and forecasts, process intent, and incentivizing business outcomes;
• allows leadership to address systemic issues;
• data is not just reported, but means something and is acted upon through decision-making and/or improvements
• # of epics created over time
• # of epics accepted over time
• # of MVP’s tested and successful
• Parameters configured in the tool to highlight and constrain anti-patterns
• Stimulates feedback loop to assist in making decisions on whether to refine/improve/refactor and in that case, what to refine/improve/refactor
• Strategic themes, objectives, key results, and the work in the portfolio – Epics, Capabilities, Features, Stories traceability conveyed from Enterprise to ART/Team level

Non-Functional Requirements

• On-Premise components of the ALM solution shall support 2-Factor Authentication
• SaaS components of the ALM solution shall support 2-Factor Authentication and SAML 2.0
• The system must be 508 compliant
• The system must be scalable to support up to 2000 users simultaneously with no performance degradation or reliability issues
• Must be the single-source system for all work performed in the portfolio and value streams.
• ALM is the single-source system of record for viewing and reporting roadmap status/progress toward objectives

Building your Experiment – The Minimum Viable Product (MVP)

Once you have constructed a quality hypothesis statement the product management team should begin work on building the lean business case and MVP concept. How are you going to test the hypothesis? How can we test the hypothesis adequately while also economically wrt to time, cost, and quality? What are the key features that will demonstrably support the hypothesis?

• Name First Last

agility at scale

• Case Studies
• Agile Leadership
• Agile Planning
• Agile Practices
• Agile Requirements Management
• Distributed Teams
• Large Scale Scrum (LeSS)
• Lean and Agile Principles
• Organizational Culture
• Scaled Agile Framework (SAFe)
• Scaling Agile

Implementing SAFe: Requirements Model (v6)

Table of Contents

What is the SAFe Requirements Model?

The SAFe Requirements Model is a hierarchical structure that manages and organizes requirements in large-scale Agile projects.

The SAFe Requirements Model helps organizations align their business objectives with their development efforts, ensuring that teams deliver value incrementally while focusing on the overall strategy. The SAFe Requirements Model is organized into three levels:

• Epics are high-level initiatives representing significant organizational value and span multiple planning intervals.
• Features are mid-level requirements that provide more detailed descriptions of the functionality needed to achieve the goals set forth by the Epics.
• Stories are the smallest units of work, representing individual tasks to be completed by Agile teams, typically within a single iteration.

What are SAFe Epics?

Portfolio Epics are large-scale business initiatives that drive change and provide substantial business benefits.

The strategic investment themes drive all new development, and requirements epics are derived from these decisions.

Epics are large-scale development initiatives that realize the value of investment themes.

Epics in the SAFe Requirements Model are large-scale, cross-cutting initiatives that encapsulate significant development efforts and provide substantial value to the organization or end-users. They can be business epics, which focus on delivering customer or user value, or enabler epics, which address technical or architectural enhancements to support the development of business epics. Epics typically span multiple Agile Release Trains (ARTs) and Planning Intervals (PIs), requiring collaboration and coordination among various teams.

Epics are the highest-level requirements artifact used to coordinate development. In the requirements model, they sit between investment themes and features.

• Epics are usually driven (parented by) investment themes. However, some epics can be independent (they do not require a parent to exist).
• Epics are not implemented directly. Instead, they are broken down into Features and User Stories, which the teams use for actual coding and testing.
• Epics are not directly testable. They are tested through the acceptance tests associated with the features and stories that implement them.

What are the key elements of a SAFe Epic Statement?

An Epic Statement comprises a brief description, the customer or business benefit, and the success criteria.

When documenting epics in SAFe, the following key elements are included:

What are the differences between SAFe Business Epics and Enabler Epics?

Business Epics delivers direct business value, while Enabler Epics provides the technological or architectural advancements necessary to support business Epics.

In the SAFe Requirements Model, the difference between enabler epics and business epics lies in their focus and purpose:

• Business Epics: These are large-scale initiatives aimed at delivering customer or user value, addressing new features, products, or services that have a direct impact on the organization’s business outcomes. Business epics typically focus on solving customer problems, capturing market opportunities, or improving the user experience.
• Enabler Epics: These epics focus on technical, architectural, or process enhancements that support the development and delivery of business epics. Enabler epics may not provide direct customer value but are essential for improving the organization’s underlying infrastructure, technology, or capabilities, making it easier to deliver business value more efficiently and effectively.

Business Epics and Enabler Epics in SAFe serve different but equally important roles. Business Epics are initiatives that deliver direct customer or business value. They represent substantial investments and have a clear tie to business outcomes. On the other hand, Enabler Epics support the implementation of Business Epics. They represent the necessary technological or architectural advancements that facilitate the delivery of business value. While they may not directly impact the customer, they are vital in realizing Business Epics.

What is the SAFe Portfolio Backlog?

The Portfolio Backlog is a prioritized list of Portfolio Epics.

The Portfolio Backlog within SAFe serves as the repository for upcoming Portfolio Epics. It is a prioritized list of Epics, with those at the top representing the highest priority and most significant initiatives that need to be undertaken. This backlog helps to align the organization around the most important strategic initiatives, allowing for effective decision-making and allocation of resources across the portfolio.

The Portfolio Backlog provides a clear picture of the organization’s direction and value delivery at the Portfolio level, guiding the allocation of resources, funding, and coordination of efforts across multiple Agile Release Trains (ARTs) and Solution Trains to align with the overall strategy.

What are SAFe Product Features?

SAFe Product Features are serviceable system components that provide business value and address user needs.

Features are described as follows:

Features are services provided by the system that fulfill stakeholder needs.

Within the realm of SAFe, Product Features are distinct pieces of functionality that are of value to the user or the business. They are typically larger than individual User Stories and represent services the system provides that fulfill specific user needs. Features form a critical part of the Program Backlog.

In describing the features of a product or system, we take a more abstract and higher-level view of the system of interest. In so doing, we have the security of returning to a more traditional description of system behavior, the feature.

Features as ART-Level Artifacts

A “Feature” in the SAFe Requirements Model is a high-level, functional requirement that delivers value to the end-user or customer. Features are typically part of a larger product or system and are aligned with the goals of a specific Planning Interval (PI), which usually spans 8-12 weeks.

Features live above software requirements and bridge the gap from the problem domain (understanding the needs of the users and stakeholders in the target market) to the solution domain (specific requirements intended to address the user needs).

Features are usually expressed as bullet points or, at most, a couple of sentences. For instance, you might describe a few features of an online email service like this:

Enable “Stars” for marking important conversations or messages, acting as a visual reminder to follow up on a message or conversation later. Introduce “Labels” as a “folder-like” metaphor for organizing conversations.

Feature Statement and Template

In the SAFe Requirements Model, a feature is typically documented using the following:

What are the differences between SAFe Features and SAFe Capabilities?

SAFe Features are system functionality that provides value to users, while SAFe Capabilities are higher-level functionalities that provide value to customers and stakeholders.

SAFe distinguishes between Features and Capabilities based on their level of abstraction and scope. Features at the Program Level are functionality increments that address user needs and deliver value. They are smaller in scope and more detailed compared to Capabilities. On the other hand, Capabilities are placed at the Large Solution Level, representing higher-level functionalities that deliver value to customers and stakeholders. They are typically bigger, encompass broader functionality, and may require multiple Agile Release Trains (ARTs) to implement.

The main difference between capabilities and features in the SAFe Requirements Model lies in their scope and granularity:

• Capabilities : Capabilities are high-level functional requirements that describe essential building blocks of a solution in the Large Solution level of the SAFe Requirements Model. They span multiple Agile Release Trains (ARTs) and represent the functionality needed to deliver value to end-users or customers. Capabilities provide a broader perspective on the solution and help coordinate efforts among multiple ARTs working together.
• Features : Features are smaller, more granular functional requirements at the Program level in the SAFe Requirements Model. They describe specific functionalities or enhancements that deliver value within a single Agile Release Train (ART). Features are derived from capabilities and are broken down into user stories, which Agile teams implement during iterations.

In summary, capabilities are high-level, cross-ART functional requirements for large-scale solutions. At the same time, features are more granular, ART-specific requirements that deliver value as part of a product or system.

How are SAFe Features tested?

SAFe Features are tested through iteration testing, integration testing, and system demos.

The SAFe approach to testing Features involves three specific practices, ensuring functionality and integration, and they are:

• Iteration Testing , where each feature is tested during the iteration it’s developed.
• Integration Testing is where Features are tested in conjunction with other system elements to ensure they work together properly.
• System Demos allow stakeholders to inspect the integrated system and provide feedback, enabling further refinement and validation of Features.

Story-level testing ensures that methods and classes are reliable (unit testing) and stories serve their intended purpose (functional testing). A feature may involve multiple teams and numerous stories. Therefore, testing feature functionality is as crucial as testing story implementation.

Moreover, many system-level “what if” considerations (think alternative use-case scenarios) must be tested to guarantee overall system reliability. Some of these can only be tested at the full system level. So indeed, features, like stories, require acceptance tests as well.

Every feature demands one or more acceptance tests, and a feature cannot be considered complete until it passes.

What are Nonfunctional Requirements?

Nonfunctional Requirements (NFRs) are specifications about system qualities such as performance, reliability, and usability.

In SAFe, Nonfunctional Requirements (NFRs) denote the ‘ilities’ – system attributes like scalability, reliability, usability, and security. Unlike functional requirements, which define what a system does, NFRs describe how it does it. These are critical factors that shape system behavior and often have system-wide implications. NFRs are a constant consideration throughout the development process, helping to ensure that the system meets the necessary standards and delivers a satisfying user experience.

Nonfunctional Requirements as Backlog Constraints

From a requirements modeling perspective, we could include the NFRs in the program backlog, but their behavior tends to differ. New features usually enter the backlog, get implemented and tested, and then are removed (though ongoing functional tests ensure the features continue to work well in the future). NFRs restrict new development, reducing the level of design freedom that teams might otherwise possess. Here’s an example:

For partner compatibility, implement SAML-based single sign-on (NFR) for all products in the suite.

In other cases, when new features are implemented, existing NFRs must be reconsidered, and previously sufficient system tests may need expansion. Here’s an example:

The new touch UI (new feature) must still adhere to our accessibility standards (NFR).

Thus, in the requirements model, we represented NFRs as backlog limitations.

We first observe that nonfunctional requirements may constrain some backlog items while others do not. We also notice that some nonfunctional requirements may not apply to any backlog items, meaning they stand alone and pertain to the entire system.

Regardless of how we view them, nonfunctional requirements must be documented and shared with the relevant teams. Some NFRs apply to the whole system, and others are specific to a team’s feature or component domain.

How are Nonfunctional Requirements tested?

Nonfunctional Requirements are tested through methods like performance testing, usability testing, and security testing.

The testing of Nonfunctional Requirements (NFRs) in SAFe involves specialized techniques corresponding to each type of NFR. For instance, performance testing measures system responsiveness and stability under varying workloads. Usability testing assesses the system’s user-friendliness and intuitiveness. Security testing evaluates the system’s resistance to threats and attacks. By testing NFRs, teams ensure that the system delivers the right functionality and provides the right quality of service, thereby maximizing user satisfaction and trust.

Most nonfunctional (0…*) requirements necessitate one or more tests. Instead of labeling these tests as another form of acceptance tests and further overusing that term, we’ve called them system qualities tests. This name implies that these tests must be conducted periodically to verify that the system still exhibits the qualities expressed by the nonfunctional requirements.

What is the SAFe ART Backlog?

The SAFe Program Backlog is a prioritized list of features awaiting development within an Agile Release Train.

Within SAFe, the Program Backlog serves as a holding area for upcoming Features, which are system-level services that offer user benefits and are set to be developed by a specific Agile Release Train (ART). These Features are prioritized based on their value, risk, dependencies, and size. The backlog helps provide transparency and drives PI planning, guiding the ART toward achieving the desired outcomes.

Features are brought to life by stories. During release planning, features are broken down into stories, which the teams utilize to implement the feature’s functionality.

What are SAFe User Stories?

SAFe User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the capability, usually a user or customer.

User Stories within SAFe are a tool for expressing requirements. They focus on the user’s perspective, facilitating a clear understanding of who the user is, what they need, and why they need it. User Stories promote collaboration and customer-centric development by emphasizing value delivery and verbal communication.

What is the definition of a SAFe User Story?

A SAFe User Story is a requirement expressed from the end-user perspective, detailing what the user wants to achieve and why.

In SAFe, a User Story is an informal, natural language description of one or more features of a software system. It is centered around the end-user and their needs, providing context for the development team. User stories are the agile alternative to traditional software requirements statements (or use cases in RUP and UML), serving as the backbone of agile development. Initially developed within the framework of XP, they are now a staple of agile development in general and are covered in most Scrum courses.

In the SAFe Requirements Model, user stories replace traditional software requirements, conveying customer needs from analysis to implementation.

A user story is defined as:

A user story is a concise statement of intent that outlines what the system needs to do for the user.

Typically, user stories follow a standard (user voice) format:

As a <role>, I can <activity> so that <business value>.

This format encompasses elements of the problem space (the delivered business value), the user’s role (or persona), and the solution space (the activity the user performs with the system). For example:

“As a Salesperson (<role>), I want to paginate my leads when I send mass e-mails (<what I do with the system>) so that I can quickly select a large number of leads (<business value I receive>).”

What are the 3-Cs of user stories?

The 3-Cs of user stories refer to Card, Conversation, and Confirmation.

In the realm of SAFe, these three Cs are fundamental to the creation and execution of User Stories. The “Card” typically represents the User Story, written in simple language. “Conversation” signifies the collaborative discussions that clarify the details of the User Story and refine its requirements. “Confirmation” establishes acceptance criteria to determine when the User Story is completed successfully. This trio of components ensures clarity and shared understanding in value delivery.

• “Card” refers to the two or three sentences that convey the story’s intent.
• “Conversation” involves elaborating on the card’s intent through discussions with the customer or product owner. In other words, the card also signifies a “commitment to a conversation” about the intent.
• “Confirmation” is the process by which the team, via the customer or customer proxy, determines that the code fulfills the story’s entire intent.

Note that stories in XP and Agile are often manually written on physical index cards. However, agile project management tools usually capture the “card” element as text and attachments in the enterprise context. Still, teams frequently use physical cards for planning, estimating, prioritizing, and visibility during daily stand-ups.

This straightforward alliteration and Agile’s passion for “all code is tested code” demonstrates how quality is achieved during code development rather than afterward.

The SAFe Requirements model represents the confirmation function as an acceptance test verifying that the story has been implemented correctly. We’ll refer to it as story acceptance tests to distinguish it from other acceptance tests and consider them an artifact separate from the (user) story.

The model is explicit in its insistence on the relationship between the story and the story acceptance test as follows:

• In the one-to-many (1..*) relationship, every story has one (or more) acceptance tests.
• It’s done when it passes. A story cannot be considered complete until it has passed the acceptance test(s).

Acceptance tests are functional tests that confirm the system implements the story as intended. Story acceptance tests are automated whenever possible to prevent the creation of many manual tests that would quickly hinder the team’s velocity.

What is the difference between SAFe Enabler Stories and SAFe User Stories?

SAFe Enabler Stories support the exploration, architecture, infrastructure, and compliance activities needed to build a system, unlike User Stories, which focus on end-user functionality.

The main difference between an enabler user story and a typical user story in the SAFe Requirements Model lies in their focus and purpose:

• Enabler Story: An enabler story represents work needed to support the development of a product or system but does not necessarily deliver customer value directly. Enabler user stories are used to address technical or architectural needs, reduce technical debt, or improve infrastructure. They are often larger and more complex than typical user stories, as they address non-functional requirements crucial for the product’s success.
• User Story: A typical user story represents a specific feature or functionality that delivers value to the customer or end-user. Typical user stories are more focused and granular than enabler user stories, describing specific actions or behaviors the user can perform with the product. They are usually smaller and more straightforward than enabler user stories, making them easier to estimate and prioritize.

Enabler Stories in SAFe facilitate the technical aspects of the system under development, such as architectural advancements or exploration activities. They differ from User Stories, which are primarily concerned with user-facing functionalities. Although Enabler Stories do not directly deliver user-valued functionality, they are vital for the evolution of the system and the delivery of future user value.

What are User Story sub-tasks?

User Story sub-tasks are smaller, manageable tasks derived from a User Story to facilitate its implementation.

Sub-tasks provide a way to break down a User Story into smaller, actionable pieces of work. These smaller tasks make the implementation more manageable and provide a clear path to completion. Sub-tasks can be assigned to different team members and tracked separately, providing a granular view of progress toward completing the User Story.

To ensure that teams fully comprehend the work required and can meet their commitments, many agile teams adopt a detailed approach to estimating and coordinating individual work activities necessary to complete a story. This is done through tasks, which we’ll represent as an additional model element:

Tasks implement stories. Tasks are the smallest units in the model and represent activities specific team members must perform to achieve the story. In our context:

A task is a small unit of work essential for completing a story.

Tasks have an owner (the person responsible for the task) and are estimated in hours (typically four to eight). The burndown (completion) of task hours indicates one form of iteration status. As suggested by the one-to-many relationship shown in the model, even a small story often requires more than one task, and it’s common to see a mini life cycle coded into a story’s tasks. Here’s an example:

• Task 1: Define acceptance test—Josh, Don, Ben
• Task 2: Code story—Josh
• Task 3: Code acceptance test—Ben
• Task 4: Get it to pass—Josh and Ben
• Task 5: Document in user help—Carly

In most cases, tasks are “children” of their associated story (deleting the story parent deletes the task). However, for flexibility, the model also supports stand-alone tasks and tasks that support other team objectives. This way, a team need not create a story to parent an item like “install more memory in the file server.”

What are User Story Acceptance tests?

User Story Acceptance tests are predefined criteria that a User Story must meet to be considered complete.

Acceptance tests for User Stories in SAFe provide clear, specific criteria determining when the story is done. These criteria are defined by the Product Owner in collaboration with the team and quality specialists and are based on the user’s expectations. They ensure the delivered functionality meets the desired value and quality, driving user satisfaction.

What are User Story Unit Tests?

User Story Unit Tests are low-level tests designed to verify the functionality of individual components of a User Story.

Unit tests in the context of User Stories involve testing individual components or units of the software to ensure they perform as expected. Developers typically create these tests during the implementation of the User Story. They form the first line of defense in catching and correcting defects, ensuring the integrity of the codebase, and promoting high-quality delivery.

Unit tests verify that the smallest module of an application (a class or method in object-oriented programming; a function or procedure in procedural programming) functions as intended. Developers create unit tests to check that the code executes the logic of the specific module. In test-driven development (TDD), the test is crafted before the code. Before a story is complete, the test must be written, passed, and incorporated into an automated testing framework.

Mature agile teams employ extensive practices for unit testing and automated functional (story acceptance) testing. Moreover, for those in the process of implementing tools for their agile project, adopting this meta-model can provide inherent traceability of story-to-test without burdening the team. Real Quality in Real Time

The fusion of crafting a streamlined story description, engaging in a conversation about the story, expanding the story into functional tests, augmenting the story’s acceptance with unit tests, and automating testing are how Scaled Agile teams achieve top-notch quality during each iteration. In this manner: Quality is built in, one story at a time. Ongoing quality assurance is accomplished through continuous and automated execution of the aggregated functional and unit tests.

How are Stories used in User Research or Data Science contexts?

Stories in User Research or Data Science represent hypotheses or questions about user behavior that need to be answered using data.

In User Research or Data Science, stories often take the form of hypotheses or research questions about user behavior. These stories guide the research process, providing clear objectives and helping to structure the analysis. By focusing on the user and their needs, these stories promote a user-centric approach to data analysis, helping to uncover meaningful, actionable insights.

Research (User Research, Data Science Research, etc.) has become integral to software development in today’s data-driven landscape. Like traditional software development, research activities also benefit from breaking work into smaller, manageable tasks. Although not officially part of the SAFe Requirements Model, we have devised a variation on the user story to address this unique aspect of data science projects. This document integrates with the team level in SAFe, ensuring that data science work aligns with Agile principles and practices.

What is a hypothesis test?

A hypothesis test is a statistical method used to make decisions or draw conclusions about population parameters based on sample data.

Within the statistical domain, hypothesis testing serves as a cornerstone methodology. It’s a process that allows analysts to test assumptions (hypotheses) about a population parameter. It involves formulating a null and alternative hypothesis, choosing a significance level, calculating the test statistic, and interpreting the results. This technique enables uncertainty-free decision-making, allowing organizations to draw data-driven conclusions and make informed decisions.

What is a hypothesis test in an Agile context?

A hypothesis test in an Agile context is a method used to validate assumptions about user behavior, system performance, or other product aspects based on collected data.

Hypothesis testing in Agile, particularly in fields like AI, research, data science, or user research, is a powerful tool for evidence-based decision-making. It involves creating a hypothesis about a particular user behavior, system characteristic, or other aspect of the product. This hypothesis is tested using real-world data collected from users, system logs, experiments, or other sources. The hypothesis test results confirm or reject the initial assumptions, providing insights into product development and improvement. It aligns with the Agile principle of learning through iteration, allowing teams to make data-informed decisions and continuously improve the product based on user feedback and empirical evidence.

What are Analytical Stories, and how are they used for data-driven insights?

Analytical Stories are questions or hypotheses guiding data analysis to obtain valuable business insights.

Analytical stories focus on data-driven insights, predictions, or recommendations that help solve business problems or enhance decision-making. They describe the desired outcome or question to be answered using data analysis, machine learning, or AI techniques. Analytical stories typically involve data exploration, feature engineering, model development, and validation. They include a clear objective, relevant data sources, and success criteria to measure the effectiveness of the analysis.

A typical Analytical Story includes the following seven elements:

What are Infrastructure Tasks?

Infrastructure Tasks are activities related to setting up or maintaining the technical environment that supports software development.

Infrastructure Tasks within SAFe encompass the essential activities that enable and support the development and delivery of software. These tasks range from setting up development environments and configuring servers to maintaining databases and managing network resources. While these tasks may not directly contribute to end-user features, they create a stable, efficient environment for delivering value. They are thus an integral part of the SAFe framework.

What is the Team Backlog?

Scaled Agile teams must maintain the utmost efficiency to ensure overall organizational effectiveness. To achieve this, we must adopt the simplest and leanest possible requirements model that caters to the needs of all stakeholders, especially team members. This model must be quintessentially agile, consistent with most agile training and common practice, and devoid of unnecessary administrative overhead, manual traceability, reporting, or detailed requirements.

Initially introduced by Scrum as a product backlog , the term “backlog” has evolved in our enterprise model to accommodate various levels of work. As a result, we use the term backlog in a more generalized sense. In the Big Picture, we refer to the backlog we’re discussing here as the Scaled Agile team’s local backlog.

This local backlog is the Scaled Agile team’s single, definitive source of work, containing all tasks (primarily user stories) that must be completed. Managed and maintained by the team, it serves as their repository for all identified work items, with its contents typically of little concern to others within the enterprise. The team has full autonomy over managing, tooling, and organizing their backlog to meet their iteration objectives.

The product owner, a Scaled Agile team member, is responsible for maintaining and prioritizing the backlog.

The Scaled Agile team’s backlog consists of all the team’s identified work items. In the meta-model, we generically refer to these work items as stories (or backlog items). For our purposes, we define a story as follows:

A story is a work item contained in the team’s backlog.

This simple definition encapsulates the agile approach’s focus on value delivery. The user story is a special kind that defines the system’s behavior and value for the user. We need to expand the model slightly to make the user story explicit.

With this minor addition, the backlog now consists of user stories and other work items. Other work items include refactors, defects, support and maintenance, tooling, and infrastructure work. These other work items help the team track all tasks needed to deliver value and enable better estimation of the time required to deliver user stories. We will discuss the rationale for specifically identifying these other work items later.

What is the SAFe Product Roadmap?

The SAFe Product Roadmap visually summarizes a product’s direction, highlighting upcoming features and milestones.

The Product Roadmap in SAFe outlines the anticipated journey of a product over time. It visually communicates the direction and progress of the product by displaying upcoming Features and Significant Milestones. This roadmap aids in setting expectations for stakeholders and helps align teams toward common objectives. It is a strategic tool that shows a high-level view of the product’s evolution while providing a common understanding of its future direction.

What is the composition and purpose of the Product Roadmap?

The Product Roadmap comprises planned features, milestones, and timelines to align stakeholders on a product’s future direction.

The Product Roadmap in SAFe combines planned Features, significant Milestones, and Timelines.

• Features derived from the Program Backlog represent the upcoming functionality increments.
• Milestones denote important events or achievements.
• Timelines provide a temporal context for the Features and Milestones.

The central purpose of the roadmap is to provide a shared understanding of the product’s future direction among all stakeholders. It aids expectation management, facilitates strategic decision-making, and promotes team alignment.

The Roadmap comprises a series of planned release dates, each with a theme and a prioritized set of features. Although it is mechanically simple to represent the Roadmap, determining its content is different.

The outcomes of release planning are utilized to update the (product or solution) Roadmap, which offers an understanding of how the enterprise aims to deliver increasing value over time.

How do you balance flexibility and expectation management with Product Roadmaps?

Balancing flexibility and expectation management with Product Roadmaps involves frequent revisiting, stakeholder communication, and applying a rolling wave planning approach.

Achieving the right balance between flexibility and expectation management when dealing with Product Roadmaps involves three specific activities, and they are:

• The roadmap is a living document that is revisited and updated frequently to adapt to changing circumstances.
• Regular communication with stakeholders to set and manage expectations effectively.
• Applying a rolling wave planning approach allows the teams to plan in detail for the near term while keeping a flexible outlook for the distant future. This method enables the roadmap to remain a useful strategic tool, providing direction without constraining agility.

In the SAFe Requirements Model, the Roadmap comprises a series of planned release dates, each with a theme, a set of objectives, and a prioritized feature set. The “next” release on the Roadmap is committed to the enterprise based on the work completed in the most recent release planning session. Releases beyond the next one are not committed, and their scope is somewhat vague.

Thus, the Roadmap embodies the enterprise’s current “plan of intent” for upcoming and future releases. However, it is subject to change—as development facts, business priorities, and customer needs change—therefore, release plans beyond the next release must not be used to establish external commitments.

What is the SAFe Product Vision?

SAFe Product Vision is a clear, inspiring goal representing the future state of a product.

In the SAFe Requirements Model, the Product Vision is a high-level, strategic description of the desired end state for a product or solution. The Product Vision guides Agile teams, helping them make decisions, prioritize features, and align their work with the organization’s broader objectives. Fostering a shared understanding and commitment across teams and stakeholders is essential, ensuring consistent direction throughout the product development process.

What are the key elements of the SAFe Product Vision?

The key aspects of the SAFe Product Vision include target state, customers, needs, and differentiation.

The Product Vision addresses six specific questions, and they are:

• What is this program’s strategic intent?
• What problem will the application, product, or system resolve?
• What features and benefits will it offer?
• Who will it cater to?
• What performance, reliability, etc., will it deliver?
• What platforms, standards, applications, etc., will it support?

The Product Vision in SAFe defines the ‘target state’ – a snapshot of the product’s desired future. It identifies customers or the audience who will benefit from the product. It outlines ‘needs’ – the problems or challenges the product will address. Lastly, it spells out ‘differentiation’ – how the product stands out from its competitors. Together, these components shape a comprehensive and compelling vision that informs and motivates everyone involved in the product’s development.

How is the SAFe Product vision documented?

The SAFe Product vision is documented using a vision statement, vision board, datasheet, draft press release, or vision box.

Since the product and software requirements specification documents and the like are unlikely to exist, directly communicating the Vision for the Scaled Agile program must take a different form. Agile teams take a variety of approaches to communicating the Vision. These include the following: 

• Vision document 
• Vision Board
• Draft press release 
• Preliminary data sheet 
• Backlog and Vision briefing

Documenting the Product Vision in SAFe can be approached in several ways. One common method is a ‘vision statement’ – a concise, written articulation of the product’s future state. Alternatively, a ‘vision board’ is created using images and text to represent the product’s goals visually. Another approach is a ‘vision box,’ a mock-up of the product’s packaging containing key information about the product. These methods help communicate the vision clearly and compellingly, enabling all stakeholders to align their efforts toward achieving it.

Product Vision Statement and Template

The Product Vision document in SAFe typically includes the following elements:

How do you balance the Product Vision and Timelines in SAFe?

Balancing the Product Vision and Timelines in SAFe requires continuous alignment of stakeholders, prioritizing based on value, and maintaining a sustainable pace.

Achieving equilibrium between the Product Vision and Timelines in SAFe involves three strategies, and they are:

• Regular alignment of stakeholders ensures everyone understands the product’s direction and the timelines involved.
• Prioritizing Features based on their value and dependencies ensures the most impactful work is done first.
• Maintaining a sustainable pace of development prevents burnout and ensures the team consistently delivers value over time, thereby upholding the Product Vision while adhering to the set Timelines.

What is the Architectural Runway in SAFe?

Architectural Runway in SAFe is the technical foundation that supports upcoming feature delivery without substantial redesign.

In SAFe, the Architectural Runway refers to the pre-existing, evolving technical infrastructure that enables the smooth delivery of impending features, minimizing the need for extensive, time-consuming redesigns. It’s a critical part of Agile development, ensuring readiness for future iterations, and is maintained and extended by implementing Enabler Epics and stories.

What is the Purpose of Architectural Runway?

The purpose of Architectural Runway is to ensure readiness for the implementation of upcoming features with minimal redesign.

The architectural runway is defined as follows:

A system with architectural runway contains existing or planned infrastructure sufficient to allow the incorporation of current and anticipated requirements without excessive refactoring.

The primary role of the Architectural Runway in SAFe is to provide a robust, flexible technical framework that aids in the swift and efficient delivery of impending features. Organizations can avoid the delays and resources associated with substantial system redesigns by having a well-maintained Architectural Runway, thereby promoting a smooth, continuous flow of value to the end users.

What are the Architectural Requirements in SAFe?

Architectural Requirements in SAFe are the technical prerequisites necessary for feature implementation.

Architectural requirements in SAFe denote the technical conditions that must be met to facilitate the successful deployment of new features. They define the system’s architecture, design, and infrastructure guidelines. This information directs teams when constructing or modifying the system, ensuring alignment with the system’s overall design and the company’s strategic objectives.

Architectural Runway and the Enterprise Portfolio

Addressing crucial technology initiatives.

In the context of an enterprise’s portfolio of products and in the face of a series of shorter, incremental releases, architectural runway answers a crucial question:

What technology initiatives need to be underway now so that we can reliably deliver a new class of features in the next year or so?

Distinguishing from Side R&D Projects

Here, we’re not discussing side R&D projects that an enterprise may use to determine technology strategies, establish feasibility, etc. Those are localized efforts and are managed by teams or system architects. Instead, we’re discussing large-scale changes to the code base necessary to support features on the current roadmap and changes that could affect most, or even all, development teams.

Examples of Large-Scale Architectural Changes

Here are some examples:

• Implement a standard install, licensing, and user authentication model across each product in the suite.
• Convert the transaction server to a microservices-based architecture.
• Redesign the operating system to support symmetrical multiprocessing.

The Importance of Timely Implementation

These changes are not simple refactors. They will involve significant, structural changes that could affect millions of lines of code and require dozens (or even hundreds) of person-years. And, if the enterprise wants to accomplish it next year or even the year after, it must start now.

To start now, this work needs to be defined and communicated to the team like any other major initiative, even though the end-user value may be a year or so down the road.

Collaborative Maintenance of the Architectural Runway

The System Architect/Engineer continuously maintains and evolves the architectural runway in collaboration with Agile teams, allowing for faster delivery of value to customers and reducing technical debt. It is critical to enable the product’s scalability, performance, and maintainability throughout its lifecycle.

How are SAFe Architectural Epics Implemented?

SAFe Architectural Epics are implemented through prioritization, analysis, implementation, and acceptance steps within the Portfolio Kanban system.

Architectural Epics in SAFe are significant initiatives that guide the evolution of the system’s technical aspects. Their implementation follows a structured approach within the Portfolio Kanban system.

• The Architectural Epic and its benefits are documented.
• Architectural Epics are prioritization based on the cost of delay or WSJF.
• Detailed analysis, including Lightweight Business Case development, follows.
• The implementation stage begins upon approval, spanning multiple Planning Intervals (PIs) if needed.
• The acceptance step concludes the process, validating that Epic’s intended benefits have been realized.

Architectural epics will be implemented incrementally in the main code line, just like any other epic. By doing so, development teams commit to a “do no harm” refactoring approach. In other words, they implement these large-scale refactors in small increments. At each PSI, they commit to “do no harm” to the systems or its users. They roll out the architectural changes piecemeal and reveal the new capabilities to the users only when there’s sufficient infrastructure to do so. It isn’t easy. It is agile. And it does work.

How is the SAFe Architectural Runway sustained?

You sustain the SAFe Architectural Runway by continuously implementing Enabler Epics and Enabler Stories.

Sustaining the Architectural Runway in SAFe involves a continual focus on implementing Enabler Epics and Enabler Stories. These elements enhance and extend the existing technical infrastructure, ensuring it stays aligned with current and future business needs. Regularly addressing the technical debt and investing in the system’s modularity, scalability, and security are other crucial aspects of maintaining a healthy Architectural Runway. This proactive approach ensures the system remains flexible and capable of supporting the swift, efficient delivery of new features.

What are the risks of neglecting the Architectural Runway?

The continuous build-out and maintenance of new architectural runways are the responsibility of all mature agile teams. Failing to do so will result in one of two negative outcomes:

• Release dates will be missed because large-scale, just-in-time infrastructure refactoring adds unacceptable risk to scheduling.
• Failure to systematically extend the architecture means teams eventually run out of runway. New features cannot be added without significant refactoring. Velocity slows. The system eventually becomes so brittle and unstable that it has to be entirely rewritten.

How is the Architecture Maintained at the Portfolio, Program, and Team Levels?

This work must happen continuously at each Portfolio, Program, and Team level.

Portfolio Level

The Scaled Agile Portfolio-level architectural runway is achieved by defining, communicating, and implementing architecture epics that drive the company’s technology vision. Some will require significant levels of investment and consume substantial resources. In the short term, some may even reduce the velocity of current and new feature implementations. Because failing to implement them will eventually compromise the company’s position in the market, architectural epics must be visible, estimated, and planned just like any other epic.

Program Level

At the Program level, product managers, system teams, project teams, and architects translate the architectural epics into architectural features relevant to each release. They are prioritized, estimated, and resourced like any other feature. And, like features, each architectural initiative must also be conceptually complete at each release boundary to not compromise the new release.

At the Team level, refactors and design spikes are often necessary to extend the runway and are prioritized along with user stories. This way, architectural work is visible, accountable, and demonstrable at every iteration boundary. This is achieved by agreement and collaboration with system architects, product owners, and agile tech leads, who determine what spikes need to happen and when.

What are Investment Themes?

Investment themes are categories of investments aligned to SAFe’s business strategy.

In SAFe, Investment Themes are broad categories that reflect the business’s strategic objectives and are used to guide resource allocation. They serve as a way to group Portfolio Epics that align with a particular business goal or strategy. This helps the organization ensure its investments align with strategic priorities and facilitates the decision-making process for funding and resource allocation.

Themes have a longer lifespan than epics and may remain mostly unchanged for a year or more.

Investment themes (or product themes) embody the initiatives that guide an enterprise’s investment in systems, products, applications, and services. They represent crucial product or service value propositions that offer market differentiation and competitive advantage. Collecting strategic investment themes for an enterprise or a business unit within an enterprise establishes the relative investment objectives for that entity. Managers are empowered to develop the initiative in the most economically and business-sensible manner for the enterprise within the partition (budget allocation). However, they typically can only exceed the budget or borrow resources from other themes with the agreement of the relevant stakeholders. Through this process, the enterprise exercises its fiduciary responsibility by directing investment towards agreed-upon business priorities.

What is the Scaled Agile Framework (SAFe)?

The Scaled Agile Framework (SAFe) is a set of organization and workflow patterns for implementing agile practices at an enterprise scale.

SAFe is a comprehensive guideline for large-scale, complex software systems. SAFe delivers Agile practices to individual teams and across teams of teams or Agile Release Trains (ARTs). By aligning the organization around value delivery and establishing a Lean-Agile mindset, SAFe aims to increase productivity, improve product quality, and foster faster time-to-market.

Why is Scaled Agile Requirements Management Important?

Scaled Agile Requirements Management facilitates alignment, visibility, and value delivery at scale in an Agile enterprise.

Requirements management in a SAFe context is central to aligning all Agile teams to deliver customer value. It ensures the requirements are visible, understandable, and actionable across all enterprise levels – from Portfolio to Program to Team. This alignment and transparency lead to improved productivity, quality, and customer satisfaction

What are the key benefits of implementing the SAFe Requirements Model?

Implementing the SAFe Requirements Model boosts an enterprise’s alignment, transparency, agility, and customer-value delivery.

Implementing the SAFe Requirements Model presents nine specific benefits for multi-team environments, and they are:

• Enhanced Alignment : The SAFe Requirements Model aligns teams, programs, and portfolios to strategic objectives, ensuring everyone is working towards the same goals.
• Improved Transparency : By making requirements traceable and visible at all levels, the model fosters transparency and improves decision-making.
• Increased Agility : The iterative nature of the SAFe Requirements Model allows organizations to adapt quickly to changes, making them more responsive to market shifts and customer needs.
• Customer-Centric Focus : The model’s emphasis on delivering customer value ensures products and services meet customer needs, improving customer satisfaction.
• Risk Reduction : Regular feedback and iterative development reduce the risk of major failures, as issues are be identified and addressed earlier in the process.
• Higher Quality Outputs : With continuous feedback and iterative refinement, the quality of the final product or service is likely to be higher.
• Efficient Resource Utilization : With clear, traceable, and actionable requirements, teams work more efficiently, reducing wasted time and resources.
• Improved Collaboration : The model fosters a culture of collaboration and shared understanding, promoting better communication within and across teams.
• Business Success : With a focus on delivering value to customers, the SAFe Requirements Model ultimately contributes to business success by creating products and services that customers want and need.

The SAFe Requirements Model ensures that requirements are clearly understood, traceable, and actionable across all organizational levels. It promotes alignment between business strategy and technology execution, boosting efficiency and effectiveness. Fostering iterative development and continuous feedback enhances the enterprise’s agility, enabling faster response to changing customer needs. It emphasizes delivering customer value, thus improving customer satisfaction and business success.

What is the connection between SAFe and the SAFe Requirements Model?

The SAFe Framework uses the SAFe Requirements Model to structure, manage, and track requirements at all levels.

In the context of SAFe, the Requirements Model serves as a tool for organizing and understanding the diverse requirements that emerge in an enterprise context. It aids in the translation of business goals into actionable development tasks, facilitating a smoother workflow from concept to cash. It’s built to accommodate Epics, Capabilities, Features, and Stories that represent different levels of granularity in the requirements.

What is the role of the SAFe Requirements Model in modern organizations?

The SAFe Requirements Model acts as a bridge between business strategy and technology execution in modern organizations.

The SAFe Requirements Model helps translate business strategy into technological execution. Structuring requirements at different levels – Epics, Capabilities, Features, and Stories – enables better communication, clearer understanding, and more efficient implementation of strategic initiatives across the organization.

What are the disadvantages of traditional requirement management?

Traditional requirements management methods often lead to delayed feedback, limited adaptability, and misalignment between business and technology teams.

Traditional methods are often linear and rigid, expecting requirements to be fully defined upfront and rarely adapting to changes. This approach results in delayed feedback loops and a lack of agility to respond to changing business needs. Moreover, these methods often struggle to align business strategy with technology execution, leading to miscommunication, misunderstandings, and solutions that don’t meet the intended business value.

How do SAFe and Traditional Requirements Models differ?

The SAFe Requirements Model is iterative, adaptable, and focuses on delivering customer value, contrasting with traditional models, which are linear, rigid, and often business-centric.

Unlike traditional linear and fixed models, the SAFe Requirements Model allows for iterative refinement and adaptation. It promotes continuous feedback and adjustments as a project progresses, ensuring the final product meets customer needs. Moreover, it focuses on delivering customer value rather than meeting rigid business requirements. This customer-centric approach, coupled with flexibility and adaptability, differentiates the SAFe Requirements Model from traditional ones.

How does the SAFe Requirements Model extend the Agile Requirements methods?

The SAFe Requirements Model expands traditional Agile methods to accommodate large-scale, complex enterprises.

Traditional Agile methods are excellent at the team level but struggle when scaling to larger organizations. The SAFe Requirements Model addresses this by introducing a hierarchical structure for requirements that aligns with the layered structure of large enterprises. It integrates Epics, Capabilities, Features, and Stories, ensuring that business objectives are effectively translated into actionable development tasks at all organizational levels.

What are the SAFe Core Competencies?

SAFe’s seven core competencies, including Agile Product Delivery, provide a holistic approach to delivering value in a Lean, Agile, and sustainable manner.

The Scaled Agile Framework (SAFe) defines seven core competencies, and they are:

• Lean-Agile Leadership:  Inspires adoption of Agile practices.
• Team and Technical Agility:  Enhances team capabilities and technical skills.
• Agile Product Delivery:  Delivers customer value through fast, integrated delivery cycles.
• Enterprise Solution Delivery:  Manages large-scale, complex solutions.
• Lean Portfolio Management:  Aligns strategy and execution.
• Organizational Agility:  Enables quick, decentralized decision-making.
• Continuous Learning Culture:  Encourages innovation and improvement.

What are the SAFe Principles?

The SAFe Principles are a set of ten fundamental principles derived from Lean and Agile methodologies that guide the implementation of SAFe.

SAFe principles are guidelines derived from Agile practices and methods, Lean product development, and systems thinking to facilitate large-scale, complex software development projects. The ten principles that make up the SAFe framework are as follows:

• Take an economic view:  This principle emphasizes the importance of making decisions within an economic context, considering trade-offs between risk, cost of delay, and various operational and development costs.
• Apply systems thinking:  This principle encourages organizations to understand the interconnected nature of systems and components and prioritize optimizing the system as a whole rather than individual parts.
• Assume variability; preserve options:  This principle highlights the importance of maintaining flexibility in design and requirements throughout the development cycle, allowing for adjustments based on empirical data to achieve optimal economic outcomes.
• Build incrementally with fast, integrated learning cycles:  This principle advocates for incremental development in short iterations, which allows for rapid customer feedback and risk mitigation.
• Base milestones on an objective evaluation of working systems:  This principle emphasizes the need for objective, regular evaluation of the solution throughout the development lifecycle, ensuring that investments yield an adequate return.
• Make value flow without interruptions:  This principle focuses on making value delivery as smooth and uninterrupted as possible by understanding and managing the properties of a flow-based system.
• Apply cadence, and synchronize with cross-domain planning:  This principle states that applying a predictable rhythm to development and coordinating across various domains can help manage uncertainty in the development process.
• Unlock the intrinsic motivation of knowledge workers:  This principle advises against individual incentive compensation, which can foster internal competition, and instead encourages an environment of autonomy, purpose, and mutual influence.
• Decentralize decision-making:  This principle emphasizes the benefits of decentralized decision-making for speeding up product development flow and enabling faster feedback. However, it also recognizes that some decisions require centralized, strategic decision-making.
• Organize around value:  This principle advocates that organizations structure themselves around delivering value quickly in response to customer needs rather than adhering to outdated functional hierarchies.

Related Content

Mastering team and technical agility with safe.

Dive into this comprehensive exploration of Team and Technical Agility - a crucial element in contemporary organizations. This blog post intricately discusses its significance, association with the Scaled Agile Framework (SAFe), and the pivotal role it plays in achieving optimal business agility. Delve into the transformation from traditional to…

Mastering SAFe PI Planning

The SAFe planning process, particularly the Program Increment (PI) planning, is critical to achieving agile and efficient product development. By working together, key stakeholders ensure alignment and a shared understanding of product objectives and goals. Preparation activities for PI planning, the two-day PI planning event, and the outputs of…

Mastering Agile Product Delivery with SAFe

This comprehensive guide explores Agile Product Delivery in the context of the Scaled Agile Framework (SAFe). Through it, we delve into key aspects such as Business Agility, Customer Centricity, Design Thinking, Lean UX, and the principles of Developing on Cadence and Releasing on Demand. We further examine how to manage the Agile Release Train…

Implementing Essential SAFe

Discover how to effectively manage programs in a SAFe environment by understanding essential elements like Agile Release Trains, customer-centric strategies, and critical metrics to drive continuous improvement.

Name (required)

Email (required)

Privacy Preference Center

Privacy preferences.

Developing a Winning Epic Hypothesis Statement that Captivates Stakeholders using SAFe

The Scaled Agile Framework®, or SAFe, was created in 2011 and built upon the classic Agile manifesto by incorporating key ideas from the Lean methodology.

Organisations using this framework can accomplish a wide range of advantages, according to SAFe developers, such as:

20-50% increases in productivity

30-75% quicker time to market

10-50%Increases in employee engagement

Assume that in order to reap the benefits of project management, your Executive Action Team (EAT) wants to embrace a Lean-Agile mentality. If so, it needs to become proficient in crafting and presenting an Epic Hypothesis Statement (EHS). Check out the Agile certification course to learn more.

Creating a strong EHS and persuading your stakeholders to embrace your bold idea are crucial to attaining business agility and optimising development procedures. On the other hand, neglecting to do so will impede your pipeline for continuous delivery and hinder you from effectively creating functional software.

It’s imperative that you nail your EHS pitch because there is a lot riding on it. We’ve developed this useful tool to assist you pitch your Epic Hypothesis Statement to your EAT in order to support these efforts.

What Is an Executive Action Team (EAT)?

One of the cross-functional teams in the SAFe framework is the Executive Action Team (EAT). This group drives organisational transformation and eliminates barriers to systemic advancement. Additionally, the EAT will hear your EHS and choose whether or not to add it to the Epic queue.

The idea that change must originate at the top is one of the fundamental tenets of the lean-agile approach. An effective EHS pitch will pique the interest of Executive Action Team stakeholders and persuade them to adopt your Epic Hypothesis Statement.

What Is an Epic Hypothesis Statement (EHS)?

A comprehensive hypothesis that outlines an epic or sizable undertaking intended to overcome a growth impediment or seize a growth opportunity is called the Epic Hypothesis Statement (EHS).

Epics are typically customer-facing and always have a large scale. They need to assist a business in meeting its present requirements and equip it to face obstacles down the road.

The Epic Hypothesis Statement (EHS) is typically delivered to the EAT in the style of an elevator pitch: it is brief, simple, and concise, although the statement itself will be highly thorough.

Key Components of an Epic Hypothesis Statement

The Portfolio Kanban system’s initial funnelling phase is expanded upon in the Epic Hypothesis Statement. The concept started out as just one, like “adding self-service tools to the customer’s loan management portal.”

You must refine this fundamental concept into a fully realised endeavour in your role as the Epic Owner. In the event that your theory is verified, you must also describe the anticipated advantages the firm will enjoy. Your EHS also has to have leading indications that you can track as you move toward validating your hypotheses.

Let’s expand on the example of the self-service tool.

You could expand on the basic premise of integrating self-service capabilities into the loan management portal that is visible to customers if you wanted to develop an EHS. Indicate which specific tools you want to use and how they will enhance the client journey in your explanation of the initiative.

For example, the following could be considered expected benefit outcomes of this initiative:

• A reduction in calls to customer service
• Better customer satisfaction and engagement
• improved image of the brand

It’s true that some advantages would be hard to measure. Complementary objectives and key results (OKRs) are therefore quite important to include in your EHS since they will support your pitch to your EAT regarding the benefits of your EHS.

Pitching Your EHS

It’s time to submit your finished Epic Hypothesis Statement to the EAT for consideration. You need to do the following if you want to involve your stakeholders.

Make Use of Powerful Visuals

The Agile manifesto and the Portfolio Kanban system both stress the value of visualisation. Including images in your EHS pitch demonstrates to your audience that you understand these approaches in their entirety and aids with their understanding of your concept.

Explain the Applicability of Your OKRs

Your suggested endeavour and the OKRs you’ve chosen should be clearly connected. Nevertheless, it never hurts to emphasise this point by outlining how each OKR you select will assist in monitoring the advancement of your theory’s proof.

Close the Deal with a Powerful Concluding Statement

Your Epic Hypothesis Statement is ultimately a sales pitch. Handle it as such by providing a succinct yet captivating conclusion. Go over the possible advantages of your project again, and explain why you think it will help the business achieve its short- and long-term objectives.

The Perfect EHS Pitch Starts with a Great Idea

By utilising the aforementioned strategies and recommendations, you can create an extensive EHS that grabs the interest of your stakeholders. But never forget that the quality of your idea will determine how well your pitch goes.

Work with your EAT to integrate ideas that have a significant impact into your workflow for managing your portfolio. Next, choose a notion you are enthusiastic about and develop your hypothesis around it. You’ll have no trouble crafting the ideal EHS pitch.

Conclusion  To learn more about Agile and SAFe, check out the SAFe Agile certification course online.

What is Interruption Testing?

Approaches for being a lead business analyst, leave a reply cancel reply.

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

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Related Articles

Intelligence and Curiosity- How you can master POETIC leadership in Agile

How relevant is PMP Certification for Business Analyst?

Product Owner or Product Manager in SAFe: Which Do You Really Need?

What is the future of Agile Development?

Kristina Suchan

• Jul 23, 2023

E like Epic: Mastering Portfolio Epic Statements in SAFe

In the world of Agile and Lean Portfolio Management, the Portfolio Epic Statement holds a significant role. It encapsulates essential information about a Portfolio Epic in the Scaled Agile Framework (SAFe), providing clarity, alignment, and strategic direction. In this blog post, we'll delve into the details of Portfolio Epic Statements, exploring why they are crucial, what information they encompass, the timeframe of portfolio epics, and the benefits they bring to organizations.

Defining the Portfolio Epic Statement

A Portfolio Epic Statement is a concise and comprehensive description that captures the essence of a significant solution development initiative within a portfolio. It serves as a guiding document that aligns stakeholders and teams, ensuring a shared understanding of the epic's purpose, objectives, and desired outcomes. The Portfolio Epic Statement acts as a focal point for decision-making, prioritization, and ongoing collaboration throughout the epic's lifecycle.

Key Information Included in the Portfolio Epic Statement

Epic Summary: A brief overview of the epic, highlighting its purpose, business value, and strategic alignment. This section provides a snapshot of the epic's significance and its potential impact on the organization.

Business Objectives: Clearly defined business objectives articulate the desired outcomes and benefits expected from the epic. These objectives align with the organization's strategic goals and serve as a guiding compass for solution development.

Hypothesis Statement: The epic hypothesis outlines the assumptions and expectations associated with the epic's success. It serves as the foundation for the Minimum Viable Product (MVP) and guides the validation process throughout the epic's implementation.

Target Customers and User Segments: Identifying the target customers and user segments helps focus the solution development efforts and ensures the epic addresses the specific needs of the intended audience.

Success Criteria: Defining measurable success criteria allows stakeholders to evaluate the epic's impact and determine its effectiveness. These criteria provide clear benchmarks for assessing the epic's progress and validating its outcomes.

Timeframe of the Portfolio Epic

A portfolio epic operates within a defined timeframe, typically spanning multiple Program Increments (PIs) in SAFe. The specific duration may vary based on the complexity and scope of the epic. The timeframe provides a strategic planning horizon, enabling organizations to allocate resources, establish milestones, and monitor progress effectively.

Every portfolio epic has an assigned Epic Owner who takes responsibility for its successful delivery. The Epic Owner acts as the primary advocate for the epic, collaborating with Product and Solution Management, System Architects, and other stakeholders. They drive the epic's implementation, coordinate backlog refinement, and prioritize the development of features and capabilities.

Benefits of Portfolio Epic Statements

Alignment and Clarity: The Portfolio Epic Statement brings stakeholders and teams together, ensuring a shared understanding of the epic's purpose, objectives, and expected outcomes. It aligns the organization's efforts towards a common goal, reducing ambiguity and improving collaboration.

Strategic Direction: By articulating the epic's business objectives and alignment with strategic goals, the Portfolio Epic Statement provides a clear direction for solution development. It helps prioritize initiatives, allocate resources effectively, and make informed decisions throughout the epic's lifecycle.

Risk Mitigation: The hypothesis statement within the Portfolio Epic Statement guides the validation process, reducing the risk of investing in solutions that may not meet customer needs. It promotes an iterative and data-driven approach, enabling organizations to learn, adapt, and make course corrections as necessary.

Stakeholder Engagement: The Portfolio Epic Statement serves as a powerful communication tool, engaging stakeholders at all levels of the organization. It facilitates transparency, fosters collaboration, and encourages active participation in the epic's definition, planning, and execution.

Portfolio Epic Statements play a crucial role in the SAFe methodology, providing a clear and concise description of significant solution development initiatives within a portfolio. By capturing essential information, defining business objectives, and guiding the hypothesis-driven approach, these statements empower organizations to deliver value-driven solutions, mitigate risks, and align efforts strategically. Embrace the power of Portfolio Epic Statements and unlock the full potential of your Lean Portfolio Management endeavors.

Ready to master the art of Lean Portfolio Management? Explore our comprehensive training courses and resources to enhance your SAFe knowledge and skills. Don't miss out on driving impactful business value with well-defined Portfolio Epic Statements. Check out our book, "Mastering the Art of Lean Portfolio Management with SAFe ," and start your journey today.

• Lean Portfolio Management Lexicon

Recent Posts

Mastering Portfolio Epics: How to Drive Business Success with SAFe

What Is Portfolio Kanban System and Why Is It Important?

How to Measure the Success of Your Lean Portfolio Management Implementation

Understanding Leading Indicators in Product Development and Innovation

It’s quite common for people to nod knowingly when you mention leading indicators, but in reality, few people understand them. I believe people struggle with leading indicators because they are counterintuitive, and because lagging indicators are so ingrained in our current ways of working. So, let’s explore leading indicators: what they are, why they’re important, how they’re different from what you use today, and how you can use them to improve your innovation and product development .

What Are Leading and Lagging Indicators?

Leading indicators (or leading metrics) are a way of measuring things today with a level of confidence that we’re heading in the right direction and that our destination is still desirable. They are in-process measures that we think will correlate to successful outcomes later. In essence, they help us predict the future.

In contrast, lagging indicators measure past performance. They look backwards and measure what has already happened.

Take the example of customer experience (CX). This is a lagging indicator for your business because the customer has to  have  the experience before you can measure it. While it’s great to understand how your customers perceive your service, by the time you discover it sucks it might be too late to do anything about it.

ROI is another example of a lagging indicator: you have to invest in a project ahead of time but cannot calculate its returns until it’s completed. In days gone by you might have worked on a new product and spent many millions, only to discover the market didn’t want it and your ROI was poor.

Online retailers looking for leading indicators of CX might look instead at page load time, successful customer journeys, or the number of transactions that failed and ended up with customer service. I often tell clients that if these leading indicators are positive, we have reason to believe that CX, when measured, will also be positive.

Don Reinertsen shares a common example of leading vs. lagging indicators: the size of an airport security line is a leading indicator for the lagging indicator of the time it takes to pass through security screening. This makes sense because if there is a large line ahead of you, the time it will take to get through security and out the other side will be longer. We can only measure the total cycle time once we’ve experienced it.

If you operate in a SAFe ®  context , the success of a new train PI planning (which is a lagging indicator) is predicated on leading indicators like identifying key roles, training people, getting leadership buy-in, refining your backlog, socializing it with the teams, etc.

Simple Examples of Successful Leading Indicators

The Tesla presales process is a perfect example of how to develop leading indicators for ROI. Tesla takes refundable deposits, or pre-orders, months if not years before delivering the car to their customers. Well before the cars have gone to production, the company has a demonstrated indicator of demand for its vehicles.

Back in the 90s, Zappos was experimenting with selling shoes online in the burgeoning world of e-commerce. They used a model of making a loss on every shoe sold (by not holding stock and buying retail) as a leading indicator that an online shoe selling business would be successful before investing in the necessary infrastructure you might expect to operate in this industry.

If you are truly innovating (versus using innovation as an excuse for justifying product development antipatterns, like ignoring the customer) then the use of leading indicators can be a key contributor to your innovation accounting processes. In his best-selling book,  The Lean Startup , Eric Ries explains this concept. If you can demonstrate that your idea is moving forward by using validated learning to prove problems exist, then customers will show interest before you even have a product to sell. Likewise, as Dantar P. Oosterwal demonstrated in his book,  The Lean Machine , a pattern of purchase orders can be a leading indicator of product development and market success.

Leading Indicators Can Be Near-term Lagging Indicators

Let’s loop back and consider the definitions of leading and lagging indicators.

• Lagging: Measures output of an activity. Likely to be easy to measure, as you’ve potentially already got measurement in place.
• Leading: Measures inputs to the activity. Often harder to measure as you likely do not do this today.

Think about the process of trying to lose weight. Weight loss is a lagging indicator, but calories consumed and exercise performed are leading indicators, or inputs to the desired outcome of losing weight.

While it’s true that both calories consumed and exercise performed are activities that cannot be measured until they’re completed, and therefore might be considered  near-term lagging indicators , they become leading indicators because we’re using them on the path to  long-term lagging indicators . Think back to the CX example: page load time, successful customer journeys, and failed transactions that end up with customer service can all be considered near-term lagging indicators. Yet we can use them as leading indicators on a pathway to a long-term lagging indicator, CX.

How to Ideate Your Leading Indicators

The most successful approach I’ve applied with clients over many years is based on some work by Mario Moreira, with whom I worked many moons ago. I’ve tweaked the language and application a little and recommend you create a Pathway of Leading to Lagging Indicators. To demonstrate this, I will return to the CX example.

If we walk the pathway, we can estimate that an acceptable page load time will lead to a successful user journey, which—if acceptable—will then lead to fewer failed transactions that revert to customer service, which ultimately will lead to a positive customer experience metric.

Work Backwards from Your Lagging Indicator

To create your Leading to Lagging Pathway, start from your lagging indicator and work backwards looking at key successful elements that need to be true to allow your lagging indicator to be successful.

At this stage, these are all presuppositions; as in, we believe these to be true. They stay this way until you’ve collected data and can validate your pathway. This is similar to how you need to validate personas when you first create them.

Add Feedback Loop Cycle Times

Once you have your pathway mapped out, walk the pathway forward from your first leading indicator and discuss how often you can and should record, analyze, and take action for that measure. You should make these feedback loops as short as possible because the longer the loop, the longer it will take you to learn.

All that’s left is to implement your Leading to Lagging Pathway. You may find a mix of measures, some which you measure today and some you don’t. For those you already do measure, you may not be measuring them often enough. You also need to put in place business processes to analyze and take action. Remember that if measures do not drive decisions, then your actions are a waste of resources.

Your leading indicator might be a simple MVP. Tools like QuickMVP can support the implementation of a Tesla-style landing page to take pre-orders from your customers.

Applying Leading Indicators in Agile Product Management

A common anti-pattern I see in many product management functions is a solution looking for a problem. These are the sorts of pet projects that consume huge amounts of R&D budget and barely move the needle on profitability. Using design thinking and Lean Startup techniques can help you to validate the underlying problem, determine the best solution, and identify whether it’s desired by your potential customers and is something you can deliver profitably.

In SAFe, leading indicators are an important element of your epic benefit hypothesis statement. Leading indicators can give you a preview of the likelihood that your epic hypothesis will be proven, and they can help deliver this insight much earlier than if you weren’t using them. Insight allows you to pivot at an earlier stage, saving considerable time and money. By diverting spending to where it will give a better return, you are living by SAFe principle number one,  Take an economic view .

Let’s look at some working examples demonstrating the use of leading indicators.

I hope you can now see that leading indicators are very powerful and versatile, although not always obvious when you start using them. Start with your ideation by creating a Leading to Lagging Pathway, working back from your desired lagging indicator. If you get stuck, recall that near-term lagging indicators can be used as leading indicators on your pathway too. Finally, don’t feel you need to do this alone, pair or get a group of people together to walk through this process, the discussions will likely be valuable in creating alignment in addition to the output.

Let me know how you get on. Find me on the  SAFe Community Platform  and  LinkedIn .

About Glenn Smith

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

View all posts by Glenn Smith

Back to: All Blog Posts

Next: traits of the stoic agilist, privacy overview.

• Business Strategy
• Docs & Reports
• Human Resources
• Marketing & Sales
• Product Management
• Productivity
• Project Planning
• Software Development / IT

SAFe lean business case template

By scaled agile, inc..

Create a lean business case for your portfolio epic based on SAFe agile practices

Having one standardized and organized method to keep track of all of your portfolio epics is essential to successful lean portfolio management . Moreover, adopting SAFe practices allows you to manage opportunities and risks via lean business cases that are implemented through the build-measure-learn SAFe Lean Startup Cycle . With this template, you’ll be able to document a business case based on a benefit hypothesis and a defined MVP, rather than a speculative ROI that would require the full potential investment. With Confluence, you can organize all of your portfolio epic documentation in one space, making it easy to analyze inputs, record decisions, and keep everyone aligned to a common objective. Read more on the SAFe epic article .

How to use the SAFe lean business case template

Step 1. determine the scope and details of the epic..

The creation of the business case is usually the primary responsibility of the epic owner. Before diving into the creation of your lean business case, set the stage for this portfolio epic. Make sure you are creating the lean business case at the right time. It is part of the analyzing phase of the portfolio Kanban system. Too early would create waste, and too late risks making investments without understanding the context. First, decide who will be involved in the proposal, to ensure that all sponsoring stakeholders are included. Then, concisely describe the epic, define how the success of the epic will be measured in the Business Outcomes Hypothesis, and establish what leading indicators will be used to indicate progress. This will help you determine the scope of the epic, and most importantly, how to define your MVP. Make sure to include any background analyses you conducted, and leave space to capture the final go/no-go recommendation.

Step 2. Create the lean business case.

Once you’ve laid down the groundwork, you’re ready to write the lean business case. Start by using the Epic Hypothesis Statement to describe the epic. This provides a short and concise way to define the business rationale, or the “why” of this Epic. Then define what is in and out of scope for this epic, as well as any nonfunctional requirements. Then define the MVP that will be used to test the hypothesis, as well as potential features this MVP will spawn Estimate the cost, preferably in the same currency used to run participatory budgeting . Don’t forget to provide an estimate of the overall cost of the Epic, once the MVP is successful. Lastly, document the kind of value return that is expected from the investment in the epic. 

Step 3. Document any supporting data.

Document the solution analysis that was carried out during the analyzing phase. Reference any additional resources, links, and supporting evidence so other team members and stakeholders can access it easily. Ensure that the attachments are labeled, using the Notes and Comments section to jot down any miscellaneous evidence. All of this informs the upcoming go/no-go decision. Be careful of information overload. The lean business case was created to make the process of laying out a business case faster and to make the review process easier. Attaching too many support documents in this field can slow down the reviewers and negate some of the benefits.  Alternatively, this space can be used to document notes during your team planning meetings.

Step 4. Keep the epic up to date.

As analysis and implementation of the MVP continue, keep the lean business case up to date to facilitate any portfolio review meetings or future portfolio funding.

Scaled Agile, Inc. is the provider of the Scaled Agile Framework (SAFe). Through courses, trainings, partners, and solutions, Scaled Agile, Inc. provides practices for scaling agile practices across the entire company. Through SAFe, they empower large and complex organizations to achieve the benefits of Lean-Agile software and systems development at scale.

More partners templates     View all

1-on-1 meeting.

Run 1-on-1 meetings and maintain productive working relationships.

AWS architecture diagram

Visualize your infrastructure to better identify weaknesses and pinpoint places for refinement.

Brainstorming

Plan, run, and document a remote brainstorming session for your next great idea.

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

A strategic inflection point is that moment when some combination of technological innovation, market evolution, and customer perception requires the company to make a radical shift or die. —Andy Grove,  Only the Paranoid Survive  

A SAFe portfolio contains one or more Development Value Streams , each dedicated to building, deploying, and supporting a set of Solutions the enterprise needs to accomplish its business mission. In the small-to-midsize enterprise, one SAFe  Portfolio  can typically govern the entire solution set. In larger enterprises—usually those with more than 500 to 1,000 practitioners—there can be multiple SAFe portfolios, often one for each line of business, or as otherwise structured around the business organization and operating model.

In either case, the portfolio is not the entire business, which is concerned with more than just solution development. Therefore, the enterprise and portfolio stakeholders must ensure that each portfolio solution set evolves to meet the broader business needs. This capability is critical to  Business Agility .

SAFe’s primary focus is helping the people who build the world’s most important systems do so faster and better. However, these new solution investments are driven directly by the enterprise strategy. Defining that strategy, deciding how much to invest in the solutions, and driving successful execution is critical for every business. This article describes the necessary collaborations and interactions between enterprise stakeholders and the portfolios for formulating strategy, determining budget allocations, and implementing important enterprise initiatives.

SAFe Portfolios within the Enterprise

Smaller enterprises and government agencies may only have a single SAFe portfolio, which is able to build all the digitally-enabled solutions needed to fulfill their mission. The portfolio is connected to the enterprise strategy by portfolio Strategic Themes and allocated an approved budget. These elements are established via a collaboration between the enterprise and portfolio stakeholders, as Figure 1 illustrates.

However, many of the world’s largest organizations use SAFe. These enterprises have thousands, and even tens of thousands, of IT, system, application, and solution development practitioners. Not all of these practitioners work on the same solutions or within the same development value streams. It’s more likely that IT and development personnel are organized to support various lines of business, internal departments, customer segments, or specific business capabilities. In this case, each portfolio is connected to the enterprise as previously described, but with three additional considerations, as highlighted in Figure 2.

• Decisions must be made on how best to allocate the total investment in solutions across multiple individual portfolios.
• The enterprise strategy has to be translated into sets of strategic themes, one for each portfolio.
• In addition, there are likely to be enterprise initiatives that will be cross-cutting, i. e. they will affect more than one portfolio. To address this case, many enterprises implement an enterprise Kanban system, which visualizes the flow of ‘enterprise epics’.

Each of the major elements of Figures 1 and 2 are described in the sections below.

Enterprise Strategy Formulation

It all starts with enterprise strategy —a plan of action to achieve the mission of the enterprise. An effective strategy answers four crucial questions about the business:

• What customers and markets do we serve?
• What products and solutions do we provide?
• What unique value and resources do we bring to the endeavor?
• How will we extend these in the future?

Each enterprise must have an approach to determine its strategy.  But most generally, the best way to think about strategy is as a natural  output  of a logical and reasoned business process. Rather than leaping to conclusions or allowing the loudest or highest-ranking voice to mandate the path, a more effective approach is to collaborate and reason about the strategy  inputs . That will generally lead to agreement and alignment about what the strategy should be. One such model was described by Jim Collins in  Beyond Entrepreneurship  [1]. The adaptation in Figure 3 highlights the inputs to strategy and defines two outputs—portfolio budgets and strategic themes—that the enterprise needs to link strategy to execution.

Each input is discussed briefly below:

• Vision  – represents the future state of what the business wants to be. It’s persistent and long-lasting.
• Mission  – identifies the current business objectives that implement the enterprise vision and frame the strategy.
• Core values  – provide the immutable belief system that governs all individual and corporate behaviors and activities.
• Enterprise business drivers  – reflect the emerging industry themes and trends that affect the business.
• Distinctive competence  – Strategy naturally leverages distinctive capabilities, the unique advantages that differentiates this business from others, and provides a competitive edge.
• Financial goals  – Whether measured in revenue, profitability, market share, or other metrics, financial or other performance goals should be clear to all stakeholders.
• Competitive environment  – Competitive analysis identifies the most significant competitive threats to the business.
• Portfolio context  – Knowledge of the current state of each portfolio informs enterprise strategy. This is a critical element of enterprise strategy formulation and as such is further elaborated below.

Portfolio Context Informs Enterprise Strategy

Generally, strategic decisions are mostly centralized since they have far-reaching impacts and are often outside the scope, knowledge, and responsibilities of Agile Teams (See Principle #9 – Decentralized Decision-Making ). In addition, the business executives and leaders have the ultimate accountability for business outcomes, so they must be ultimately responsible for the strategy.

However, many factors that inform potential strategy may not be visible to those enterprise executives. Many of the business challenges, market opportunities, and conditions that exist may be local to various solution offerings. That is why strategy formulation requires continuous collaboration, communication, and alignment with downstream portfolios. In other words, developing an effective strategy demands awareness of the portfolio context. This includes Portfolio Vision , the Lean Budget Guardrails that govern the portfolio investments, and Metrics that measure business outcomes, flow, and organizational competence, and as illustrated in Figure 4.

Enterprise Portfolio Collaboration

Collaboration between the enterprise and portfolio stakeholders is critical to achieving business goals. While typically led by the most senior enterprise business and technology stakeholders, the process includes participation from portfolio stakeholders who bring important context from their respective value streams, as Figure 5 illustrates.

Participants in this critical collaboration include:

• Enterprise executives who have the ultimate responsibility for business outcomes
• Some portfolio stakeholders often have a significant role in both the portfolio vision and enterprise strategy. These can include Business Owners who have primary business and technical responsibility for ROI, system and solution architects, and members of the APMO who support successful execution and operational excellence.
• Epic Owners play a key role in moving large initiatives through and across portfolios
• Enterprise Architects help assure that strategies are anchored in feasible technological innovations. In addition, awareness of new innovations often provides new strategic opportunities

Connecting Enterprise Strategy to the Portfolio with Strategic Themes

The formulation of strategy is one of the most complex and critical enterprise endeavors. It isn’t necessarily feasible or even desirable to formally ‘document’ strategy in a highly structured way (though the Appendix below shows a good starting approach). Nor is it exactly obvious as to who needs to communicate strategy, to whom, and when.

To address this, SAFe recommends using strategic themes as a summary artifact to communicate strategic intent. In a situation where an enterprise has a single portfolio, a single set of portfolio strategic themes provide the needed connection to the enterprise strategy.

In a multi-portfolio organization, an additional set of central ‘enterprise strategic themes’ may be needed to inform and connect the strategy of the individual portfolios as is illustrated in Figure 6.

A typical format is to simply use a short phrase (e.g., ‘Expand to the European market’, ‘Transition to the cloud’, ‘Enable consumer self-service’). A more rigorous approach is to express strategic themes as OKRs (Objectives and Key Results) where a concise objective is supplemented with key results – specific, measurable achievements, which, in turn, are measured via KPIs . Either way, strategic themes communicate strategic intent to everyone in the organization.

Allocating Portfolio Budgets

An effective lean enterprise adaptively and dynamically allocates funds across portfolios to execute evolving strategy. To support this flexibility and speed of decision-making, rather than funding individual projects, SAFe enterprises instead allocate budgets to each portfolio, which is then empowered to make the investments that maximize value returned.

As described in the Lean Budgets article, each portfolio then allocates budgets to the development value streams within that portfolio.

Managing Cross-Portfolio Initiatives

In a SAFe enterprise, every solution is managed within a specific portfolio. Some initiatives, however, cut across a broad solution landscape and require the collaboration of multiple portfolios (for example, ‘implement GDPR compliance across all enterprise solutions’). Many of these are quite critical and often not subject to debate (like the GDPR example). And yet, if not managed appropriately, initiatives that come from this highest organizational level—whether they carry significant strategic importance or not—can still be ‘pushed’ onto portfolios and thus overload the system.

To address this, enterprise epics are established to define and reason about this important work. And in a manner similar to a Portfolio Kanban , the work intake process at this level helps the organization match demand to capacity, prevent overload, and foster fast delivery of enterprise value.

The process can be summarized as follows:

• All big new cross-portfolio initiatives enter the Funnel and are progressively elaborated through Review and Analysis in close interaction with the portfolios that will do the work.
• In a manner analogous to portfolio epics , the epic hypothesis statement and the lean business case can be used to define and further elaborate enterprise epics.
• A “Go” or “No-Go” decision is made once the analysis is complete.
• Portfolios then pull approved enterprise epics into implementation and create portfolio epics to describe the portion of the work they are committed to.

In a manner similar to portfolio epic owners, ‘enterprise epic owners’ foster and drive collaboration around the organization’s cross-portfolio initiatives.

In some cases, both the scope and the implementation rhythm of the corresponding portfolio epics may need to be synchronized across the portfolios. For example, even if the portfolios do not have substantial interdependencies, an enterprise epic may require a coordinated MVP (Minimal Viable Product)—a thin slice of effort across the organization— to validate or disprove the underlying business hypothesis (Figure 9). The MVP limits the risk of investment and provides for exploratory discovery of even the largest and most critical enterprise initiatives (see the SAFe Lean Startup Cycle in Epics).

Appendix: Capturing Strategy in a Business Model Canvas

The concepts outlined in this article provide a logical and reasoned process in which enterprise strategy formulation reflects internal and external objectives, business conditions, and the organization’s larger purpose. Moreover, once decided, the plan must be communicated and made clear to all stakeholders. There is, of course no ‘one right way’ to do this. One popular way to frame a strategic plan is through the Business Model Canvas (BMC) [2]. The BMC is a one-page template that summarizes the most important aspects of a business model, as illustrated in Figure 10.

Download The Business Model Canvas The BMC can be used to model any business, from startup to global enterprise. The BMC comprises nine somewhat independent building blocks that help clarify thinking and focus when describing a business model. The ‘blocks’ of the canvas are as follows:

• Value propositions  are the set of products and services the enterprise offers.
• Key partners  are the various buyer-supplier relationships and business alliances that facilitate achieving the value proposition.
• Key activities  are the most important actions the enterprise takes to deliver its products and services.
• Key resources  are the critical human, physical, intellectual, financial, and other capabilities and assets the enterprise has to achieve its objectives.
• Customer relationships  reflect the types of relationships needed to effectively apply and leverage the business’ products and services.
• Customer segments  define how the business views and treats various sets of customers differently based on their common attributes.
• Channels  explain how the enterprise delivers its products and services to intermediaries, customers, and end-users.
• Cost structure  highlights the various elements of development, production, deployment, operating, and support costs associated with the business’ products and services.
• Revenue streams  reflect how the enterprise receives financial compensation for its products and services.

Thinking Like a Lean Startup with the Lean Canvas

A popular variant of the BMC is the Lean Canvas created by Ash Mayura [3], illustrated in Figure 11 [4].

Download The Lean Canvas The lean canvas was based on the thinking that originated in Lean Startup [4] and is designed to address startup enterprises’ unique opportunities and challenges. It’s now also applied to innovation efforts in larger enterprises. The Lean Canvas is similar to the BMC, but it focuses more keenly on the nature of the problem to be solved, as well as the unique competencies of an enterprise that can be used to address emerging opportunities.

Like the BMC, the Lean Canvas has nine ‘blocks.’ The ‘channels,’ ‘customer segments,’ ‘revenue streams,’ and ‘cost structure’ is shared with the BMC. However, the Lean Canvas replaces the other five blocks with the following:

• Problem  describes the  problem  that exists in the marketplace before designing a potential solution. This is a signature aspect of  Design Thinking .
• Solution  defines the key characteristics of a proposed solution.
• Unique Value Proposition  describes the unique skills, resources, and assets a business brings to the endeavor. In other words, “why you are different and worth getting attention.” [3]
• Unfair advantage  describes the tangible and intangible assets of the business that cannot be easily bought, copied, or replicated by competitors who address the same problem.
• Key metrics  identify the critical, early measures that indicate whether the new solution is likely to address the identified problem.

The Lean Canvas helps define an actionable business plan. It focuses on customer problems, solutions, key metrics, and competitive advantages. In contrast, the Business Model Canvas is a strategic management tool, allowing you to describe, design, challenge, invent, and pivot your existing business model [5]. While neither canvas captures all the elements of an enterprise strategy, both are useful tools to evolve the organization’s solution portfolios. The choice is up to the enterprise: Use either or both canvases, or develop a derivative best suited to a particular business context.

Last update: 27 September 2021

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.