feature benefit hypothesis safe

The ART of SAFe

Applying Lean and Agile techniques at scale to bring about effective, sustainable improvement in Culture, Execution and Business Results

Monday, January 8, 2018

Effective feature templates for safe, introduction, how much detail is needed, and by when.

• Prior to WSJF assessment
• Prior to PI Planning

Feature Canvas

New Product: “The current state of the [domain] has focussed primarily on [customer segments, pain points, etc]. What existing products/services fail to address is [this gap] Our product/service will address this gap by [vision/strategy] Our initial focus will be [this segment]”

Existing Product: “Our [service/product] is intended to achieve [these goals]. We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”

“We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]”.

Sample Completed Canvas

A glimpse at how you might visualise your next WSJF estimation workshop

Detail beyond the Canvas

• User Journeys:  Some framing UX exploration is often very useful in preparing a Feature, and makes a great support to teams during PI planning.  
• Architectural Impact Assessment: Some form of deliberate architectural consideration of the potential impact of the feature is critical in most complex environments.  It should rarely be more than a page – I find a common approach is one to two paragraphs of text accompanied by a high level sequence diagram identifying expected interactions between architectural layers.
• Change Management Impacts: How do we get from deployed software to realised value?  Who will need training?  Are Work Instructions required?  

Tuning your Template

Who completes the canvas/template, 30 comments:.

Awesome work Mark! We have created some for clients too that we can't share. :-(

Thanks for sharing Mark - these are really useful. I really like the hypothesis statements for features and think that this is a major enhancement in SAFE 4.5. I wrote a blog post about it here: http://runningmann.co.za/2017/09/25/the-power-of-feature-hypotheses/ that you might be interested in.

These are awesome Mark. Thanks for sharing

Thanks for sharing your experience on this area with the community Mark. Feature Templates are a very common requirement for Agile practitioners, maybe you can persuade the SAFe community to include an artefact like this in the framework.

Information was good,i like your post. Looking forward for more on this topic. product management

This is great! Do you have the template format available so we don't have to replicate?

great stuff, how would you differentiate this from SAFe Epics

Other problems include editing resistance, lack of or significantly delayed communications and lack of professionalism. website

I discovered your blog site site on the search engines and check several of your early posts. Always maintain up the very good operate. I recently additional increase Rss to my MSN News Reader. Looking for toward reading much more on your part later on!… apple tablet mockup

I genuinely treasure your work , Great post. ipad mockups

When I originally commented I clicked the -Notify me when new surveys are added- checkbox and from now on every time a comment is added I buy four emails with similar comment. Perhaps there is any way you are able to eliminate me from that service? Thanks! web design company san francisco

Good post and a nice summation of the problem. My only problem with the analysis is given that much of the population joined the chorus of deregulatory mythology, given vested interest is inclined toward perpetuation of the current system and given a lack of a popular cheerleader for your arguments, I’m not seeing much in the way of change. web design company san francisco

Cutting up pictures, reestablishing of old photos, working around with watermarks, and other progressed tips and deceives can likewise be found in a high caliber and significant Adobe photograph shop instructional exercise. Professional graphic design

Very efficiently written information. It will be beneficial to anybody who utilizes it, including me. Keep up the good work. For sure i will check out more posts. This site seems to get a good amount of visitors. essay writing service

Their willingness to partner with us has been great. UI design agency

Hey enormous stuff or pleasant information you are offering here. best branding agencies

Nice blog Mark How can I get a downloadable version of this Canvas?

I think you can make video about it. If you want to promote your channel on youtube you can buy youtube subscribers for it

Thanks for this incredible information. I think you could make a video about feauture templates for sale and post it on Instagram. By the way if you want to get more followers for your profile, you can repeatly use the help of https://viplikes.net/buy-instagram-followers to quickly boost their number.

Socialize Club- Buy Facebook live stream views cheap in price but high in quality.We provide you with 100% Real Facebook live stream views delivered at your facebook live video instantly.

Packaging should function as a barrier to air, water vapor, dust, and other contaminants. Because food items might be in liquid form, they must be leak-proof to avoid loss during transportation. BOPP film supplier

percetakan buku online di jakarta percetakan murah jakarta percetakan online jakarta percetakan Jakarta timur cetak murah jakarta cetak online jakarta digital printing jakarta print murah jakarta jasa print murah cetak buku murah di jakarta timur

I use the aforementioned off-page SEO techniques and am currently seeing the results of my labors with page 1 Google search engine rankings. For example, Deanna Hibbs, a full-time working mother, discovered internet marketing while searching for a work schedule other than 9 to 5. SEO philadelphia

thank you for share an informative blog article with us. kitimesblog

Essential phases

This comment has been removed by the author.

Produk Elektronik Terbaik Saat Ini Bahan dapur memasak ikan Bumbu dapur ayam goreng Menjual bahan dapur Shin Tae Yong coah terbaik sepanjang masa Justin hubner bek andalan timnas indonesia Nathan Tjoe a on bek bule berdarah indonesia yang membela timnas Jualan tanpa modal hanya dengan perlengkapan dapur

agility at scale

• Team and Technical Agility Assessment Service
• Agile Product Delivery Assessment Service
• 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 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…

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…

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.

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…

Name (required)

Email (required)

Privacy Preference Center

Privacy preferences.

Try for free

Minimum Requirements for a Feature

Minimum requirements for a feature: what is a benefit hypothesis, minimum requirements for a feature: who writes acceptance criteria, feature definition.

A feature, within the scaled Agile definition (SAfe), requires a benefits hypothesis and acceptance criteria. These establish what and why you are testing and how you will determine success or failure. Each feature will usually have three key components that form the minimum requirements: Beneficiaries. These are needed upfront to establish the hypothesis and the acceptance criteria. Benefit hypothesis.  Acceptance criteria.

.css-uphcpb{position:absolute;left:0;top:-87px;} How do you write a feature in agile?

The minimum requirements already discussed can be made more detailed by covering a few related areas:

The beneficiaries.

The benefit hypothesis. 

The feature’s business value.

A clear feature description.

Acceptance criteria.

The two fundamental elements of the benefits hypothesis and the acceptance criteria can be unpacked in a little more detail to illustrate their individual and collective roles for features.

The benefit hypothesis is the business value that the feature is expected to deliver. Similar to a scientific hypothesis, this is a statement that will ultimately be tested to see if it is correct. A good formula to use is:

If (proposition), then (benefit)

The proposition is what your team plans to deliver, while the benefit is the value that this will deliver. Benefits can be business-side and include:

Increased efficiency.

Greater transparency.

Cost reductions.

Improved data streams.

Increased revenue.

On the client-side, benefits can include:

Increase customer satisfaction.

Improved functionality.

Greater simplicity for better customer experiences (CX).

How likely is this proposition able to deliver this benefit? 

Is this feature’s success rate quantifiable? 

You must be able to validate your hypothesis to measure the relative success or lack of success of the related feature. Ongoing optimization or even a decision to pivot will not be possible without the ability to quantify how well the proposition succeeded in delivering the benefit.

In Scaled Agile Frameworks (SAFe) a feature’s acceptance criteria are usually written by the stakeholder or the product owner. The acceptance criteria should provide a framework to measure whether the benefit is being delivered by the proposition. In other words, has the feature shown the benefit hypothesis to be correct? If not, is it possible to optimize or would it be better to pivot?

The main functions of acceptance criteria are:

Determine if the feature has been implemented correctly.

Establish whether the business benefits are being delivered.

Mitigate implementation risks.

Facilitate early validation testing to prevent unnecessary costs and effort.

Inform user stories and functional tests.

General FAQ

Glossary categories

Feedback Management

Prioritization

Product Management

Product Strategy

Roadmapping

Prioritize with confidence

Book a demo

Experience the new way of doing product management

SPCT Journey Webinar by Jayaprakash Prabhakar (JP) : Register Now

Understanding the Role of Features in Agile Release Trains (ARTs)

In Scaled Agile Framework (SAFe), Agile Release Trains (ARTs) play a crucial role in delivering value to customers. ARTs are long-lived, self-organizing teams that consist of Agile teams and other stakeholders necessary to continuously define, build, test, and deliver solutions. One of the key components within ARTs are features. In this blog post, we’ll dive deep into understanding what features are, how they are defined, sized, and delivered within ARTs, and their importance in delivering business value.

Related SAFe certifications

SAFe Product Owner/Product Manager certification SAFe RTE certification SAFe Agile certification RTE certification Implementing SAFe training with SPC certification

What are Features?

Features represent solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered by an ART within a Planning Interval (PI). Each feature includes a benefit hypothesis and an acceptance criteria . A benefit hypothesis is a statement that describes the proposed measurable benefit to the end user or business. Acceptance criteria determine whether the implementation is correct and delivers the intended business benefits. Features are owned by Product Managers and are placed in ART backlog as shown in the below picture. 

Features vs. Capabilities:

It’s important to note the distinction between features and capabilities. While features are delivered by a single ART within a PI, capabilities represent larger solution functionality that often spans multiple ARTs and is sized to be delivered within a PI. Capabilities are at a higher level of abstraction and support the definition and development of large solutions.

Discovering and Describing Features:

To create desirable and sustainable products, SAFe recommends using Design Thinking , a customer-centric approach. Design thinking tools such as personas, empathy maps, and customer journey maps provide a deeper understanding of customers and users, offering a rich context to better understand features and their potential benefits.

Features are defined using a feature and benefits format, which includes a short phrase giving a name and context, along with a benefit hypothesis. It’s important to avoid defining features using the ‘user story voice’ format, as features typically provide functionality for multiple user roles, and using the same method to describe user stories and features may cause confusion.

Creating and Managing Features:

Product Managers, in collaboration with Product Owners and other key stakeholders, define features in the local context of an ART. Some features may arise as a result of splitting epics, while others are created by System Architects, known as enabler features. Enabler features pave the Architectural Runway and support exploration or provide the infrastructure needed to develop, test, and integrate the solution.

The ART backlog is used to maintain both business and enabler features. At each PI boundary, the percentage of resources allocated to new features (or capabilities) versus enablers is estimated to guide the train.

Prioritizing Features:

To sequence jobs (features and capabilities) based on the economics of product development flow, SAFe uses the Weighted Shortest Job First (WSJF) prioritization model. Product and Solution Management use WSJF to prioritize features, while System and Solution Architects use it to prioritize enabler features. Since both business and enabler features exist in the same backlog, Product Management must work collaboratively with System Architects to reconcile differences in priorities considering the business needs. Aligning priorities to Strategic Themes and capacity allocation are two approaches to creating alignment and balance in the backlog.

Estimating and Accepting Features:

Feature estimation supports forecasting value delivery, applying WSJF prioritization, and sizing epics by splitting them into features and summing their estimates. Feature estimation usually occurs in the analysis state of the ART Kanban and relies on normalized estimation techniques similar to the methods used by Agile teams.

Product Management is responsible for accepting features. They use acceptance criteria to determine whether the functionality is implemented correctly and whether nonfunctional requirements are met. Acceptance criteria can also be used as the source of stories and are often transformed into acceptance tests with Behavior-Driven Development (BDD).

Splitting Capabilities into Features:

To be implemented, capabilities must be decomposed into features, which are further split into stories consumable by teams within an iteration. SAFe provides ten patterns for splitting work, including workflow steps, business rule variations, major effort, simple/complex, variations in data, data methods, deferring system qualities, operations, use-case scenarios, and breaking out a spike.

Conclusion:

Features play a vital role in delivering business value within Agile Release Trains. They represent solution functionality that fulfills stakeholder needs and are sized to be delivered within a PI. By understanding how features are defined, sized, prioritized, estimated, and accepted, organizations can effectively leverage the power of ARTs to continuously deliver value to their customers. Embracing the practices and principles outlined in the Scaled Agile Framework, such as Design Thinking, WSJF prioritization, and feature splitting patterns, can help organizations optimize their value delivery and achieve better business outcomes.

Leanwisdom is the best curated professional course provider for Project Management, Agile, and Scrum. With a desire to guide professionals in their Agile Journey. In a short span we have trained many professionals and supporting them with Cross-Skilling and upskilling, the Agile, Scrum and other Project Management domain.

You May Also Like

Understanding SAFe Roadmaps

Understanding User Stories in SAFe: The Importance of User Stories

WHAT’S NEW IN SAFe 6.0: Empowering Teams and Clarifying Responsibilities –Scrum Master’s Role Clarity

The Importance of Solution Vision for Organizational Alignment

Best Practices for Stabilizing and Operating Post-Release

How To Overcome The Challenges Faced By SAFe Scrum Masters

Utilizing Kanban Systems for Capability Delivery

What are Enablers in SAFe and its Types?

4 Roles & Responsibilities of SAFe Scrum Master(SSM)

Drop Your Query

Benefits of SAFe®

How the scaled agile framework ® benefits organizations.

More than 1,000,000 individuals in 20,000 companies around the world have acknowledged the benefits of scaling agile with SAFe. Aggregated customer case studies have shown the following typical results:

Faster Time-to-market

One of the benefits of scaling agile with SAFe is improved time-to-market. By aligning cross-functional teams of agile teams around value, leading enterprises can meet customer needs faster. Leveraging the power of Scaled Agile Framework helps them make quicker decisions, communicate more effectively, streamline operations, and stay focused on the customer.

• Johnson Controls releases 2—4x faster with 100 percent predictability

Improvements in Quality

Built-in quality is one of the core SAFe values: it highlights the importance of integrating quality into every step of the development cycle. In this way, scaling agile with SAFe benefits organizations by shifting quality from a last-minute focus to the responsibility of everyone.

• Centers for Medicare and Medicaid Services shifted from maintenance mode to modernization and lowered help desk tickets by 55 percent
• Cisco saw a 40 percent decrease in defects and new incentives for attracting talent

Increase in Productivity

SAFe provides measurable improvements in productivity by empowering high-performing teams and teams of teams to eliminate unnecessary work, identify and remove delays, continuously improve, and ensure they are building the right things.

• Chevron improved productivity with a fully supported remote workforce
• Air France teams using SAFe delivered 20% more effectively than waterfall teams

Better Employee Engagement

Better ways of working yield happier, more engaged employees. One benefit of scaling agile with the Scaled Agile Framework is helping knowledge workers achieve autonomy, mastery, and purpose, which are the key factors in unlocking intrinsic motivation. Organizations practicing SAFe have the tools to minimize burnout and increase employee satisfaction.

• Nokia Software improved its team collaboration and predictability
• Sproutloud improved predictability, employee engagement, and alignment between the business and IT

SAFe Customers in the News

• VA Benefits Platform: Big Bang, Less Bucks
• TIAA Accelerates Software Delivery with IT-Business Union
• How the US Air Force Made Its ISR Network Cheaper to Run and Easier to Upgrade
• AT&T CIO Pam Parisian: How to Gain Speed and Cut Technical Debt

Back to: What is SAFe?

SAFe, the most trusted system for learning and practicing agile ways of working, helps enterprises thrive in a world of change by linking evolving strategy to execution.

Next to: SAFe and Agile

As a framework for scaling agile, SAFe gives large, complex organizations a proven system and structured guidance for thriving in a world of change.

“ We needed a way to integrate our teams, harness their agility, and align them to enterprise objectives and guardrails…SAFe is the key to delivering value across the enterprise.” —Konstantin Popov, Program Manager

Six years ago, Mercedes Benz launched one or two products yearly in just a couple of markets. In 2022, they introduced roughly 40 products in 34 markets. By moving away from waterfall methods and adopting SAFe, they could launch better technology, operating systems, AI, and face recognition, integrate different data sources, and utilize better risk models.

SAFe allowed Mercedes-Benz to achieve the shift from hardware to software, master vehicle electrification, meet zero-emission requirements, and adapt to environmental, geopolitical, and consumer demands.

Handelsbanken, a Swedish bank known for its innovative practices, wanted to cut its time to market and improve its customer offerings. They needed a collaborative partner to contribute to those goals. The bank explored SAFe and gained trust, knowing that several large companies and banks in its region had found success with it.

With SAFe, Handelsbanken achieved its goal of enabling automated decisions for mortgages sooner than expected. The framework’s structure helped them think big, focusing on flow and results.

Privacy Overview

The Running Mann

Humorous Anecdotes, Observations & Accounts of Marathon Running & Agile Adventures.

The Power of Feature Hypotheses

One of the improvements SAFe version 4.5 introduced was incorporating practices from “ The Lean Startup ” into the framework – specifically the use of benefit hypothesis statements into features and epics. This is a story of how well this worked for us.

We were worried about the standard of feature writing across our teams and also wanted to bring them up to speed with the SAFe 4.5 feature hypothesis thinking. Therefore, we organised a Friday afternoon “Lunch and Learn” session for interested team members.

The main objective was to go over a practical example from one of our feature teams and convert an existing feature into a ‘ valuable feature hypothesis statement ‘.

[If you are unfamiliar with the Lean Startup concept of hypotheses, please see supporting post:  Using Hypothesis Statements for Features in Software Development ]

Getting A Feature Benefit Hypothesis Statement

We started with the feature captured below that, no disrespect to team, was not very well written. The definition I like to use for a well written feature is that: ‘ someone outside the team can read it once and understand what needs to be done ’. At this stage I don’t even think that most of the team understood the feature.

Luckily we had the product owner (PO) in the room. We asked him a few probing questions that went something like this.

Team: Why are we doing this change? What is the benefit? PO: We need to update the audit report fields for our customers. Team: Why do they need the additional fields. PO: So that customers can check for errors before they submit them to us for processing. Team: Why do they check for errors? How does this work? PO: All customers have a QA person or someone similar checking these reports to prevent errors being processed. When errors get missed and processed, it wastes time and causes a lot of frustration. Team: So what exactly is the current problem? PO: Today, customer auditors can’t see all the relevant information on the audit reports for cross-checking and referencing so many errors are still processed. Team: What is the intended result of this change? PO: We’ll reduce the error rate by 95%. [And BAM! We get our hypothesis]

Interesting takeout: The PO did not come right out with the “95% error reduction” even though it was in his head from the start – it required a conversation to get his knowledge shared with the rest of the team. This is part of the magic of conversation within collocated teams – and the importance of having a PO who works with the team.

The benefit hypothesis makes the “why” clear to without having to write a long document. Everyone in the room quickly came to the same understanding as to what needed to be done and why. A well worded hypothesis statement helps remove ambiguities and focuses the team on what really needs to be done. [To understand why “why?” is important – see Simon Sinek’s TED Talk below.]

The other (perhaps even more) positive outcome is that it gives “purpose” to the teams’ work. I asked the group, “Would you rather (a) update some fields on an audit report or (b) reduce error rates by 95%?” – unsurprisingly there was unanimous agreement that (b) was the more exciting option.

“Reducing error rates by 95%” gives meaning to the team’s work. I am unlikely to go home and proudly tell my kids I updated some fields on an audit report. But telling them that I helped reduce foreign exchange error rates by 95% makes my job as a developer on a transactional banking system sound sexy and important!

Feature Acceptance Criteria & Slicing

We then moved onto the feature acceptance criteria (AC). The simple way I view feature AC is, “ How will we UAT the feature to know that it’s complete and fit for purpose? ” (as opposed to user story AC which are the actual unit test cases).

If you are not able to write clear AC you don’t know enough to proceed with the feature so this was a good test of the strength of our feature hypothesis. Once again it was an interesting and valuable discussion with participants throwing various questions at the PO. A summary is below:

Which countries are in scope?

The PO initially said “all countries”. Further conversation sliced it down to two countries (South Africa and Uganda) where there was definite current need – from there it made sense to split the feature into one for each country. South Africa had the most urgent need so we focused on that and the lower priority Uganda feature went onto the backlog (where it will remain until it becomes priority). The requirement that the initial feature for South Africa be scalable for other countries was included as a non-functional requirement.

Attempted slipping in of a production defect

The PO tried to slip a production defect into the AC (the format of the onscreen and printed reports are different). The team deftly managed to slice the defect off the feature (the defect fix is roughly the same size as the eventual feature). The valid defect was added to the team backlog (where the PO can prioritise it against other work to determine when it will get fixed).

Attempted scope creep

The PO also tried to slip a new requirement into the AC – the ability to be able to save audit reports as a .pdf file. Once again the team deftly convinced the PO that this was not part of the minimum viable product (MVP) by referring to the hypothesis statement (i.e. we don’t need to save to .pdf to test the hypothesis). The valid requirement was also added to the team backlog (and the PO gets to decide when it’s priority enough to be built).

Interesting takeout: In my opinion, the PO was doing his job perfectly – trying to get as much as possible into the feature to maximise the customer benefit. Because he’s part of the overall team having the conversation he gets to understand the trade-offs involved with different decisions. When posed with the question, “Do you want to have the feature done in 2 weeks if we just do MVP or do you want to wait for 2 months if we do ‘ all this other stuff ‘?” a good PO will always go for “ small and fast “.

By reducing the feature to a single (highest priority) country and omitting other requirements that (whilst important) had no impact on the hypothesis statement, the feature ended up being at least 10 times smaller than if we’d tried to include everything. Slicing the feature down to get the most value with the least amount of work drastically increases the speed with which it can be built and dramatically reduces risk.

The team left the room knowing exactly what needed to be done. More importantly everyone had agreed on what didn’t need to be done “right now” (i.e. in the next sprint) because they were not MVP (however these requirements have been added to the team backlog and can be done when the PO prioritises them). The PO was also part of all the decisions taken so he should get no nasty surprises when the feature is presented back as “done”.

Conclusion: Super-Quick Delivery

The best part of this story was that two weeks later when I asked the team “How’s the feature going?”, the reply was “It’s already done.”

The team was able to fully design, build and test a valuable feature in less than two weeks (fitting easily into a 2-week sprint). In the past a feature like this would usually take 12 months to deliver (see the supporting post “ 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery “). By slicing the feature down to its true MVP and the team knowing exactly what was needed and why, the feature flew through the development value stream.

Of course, now the real test is to measure whether our hypothesis proves true and we successfully reduce the error rate by 95% – let’s hope so! We’ll know pretty soon…

The actual reduction in client error rates was 80%. As it stands this has been deemed sufficient. There are no plans to build additional features to further reduce the error rates (as there have been higher priority features to work on). Likewise, the production defect has not been fixed (and may never be) since it has never been a priority compared to other more beneficial work.

I delivered a presentation on “The Power of Feature Hypotheses” at Agile Africa 2018 using this and other examples. Here is the video link from the conference:  https://youtu.be/CUVX1AiqQak?list=PLp6xQ3fl72zIu8FJjDtBUFUS0w1FPQhPZ

I am also more than happy to submit a speaker proposal for your conference. Feel free to contact me via email: [email protected] or Twitter @runningmann100 /  @StuartDMann .

4 Replies to “The Power of Feature Hypotheses”

• Pingback: 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery - The Running Mann
• Pingback: Using Hypothesis Statements for Features in Software Development - The Running Mann

Good account of what we discussed in the session and what was learnt. Going forward it will definitely provide a mechanism for us to access information on the sessions to further unpack.

• Pingback: How George Costanza, Frogger & a Craving For Sushi Help Explain Features & User Stories - The Running Mann

Leave a Reply Cancel reply

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

Please enable JavaScript to submit this form.

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

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

SAFe Glossary

The SAFe glossary is a set of definitions for all SAFe Big Picture elements.  The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.

• Chinese (Simplified)
• Chinese (Traditional)
• French (Canada)
• French (France)
• Portuguese (Brazil)

The 5 Whys is a proven problem-solving technique used to explore the cause-and-effect relationships underlying a particular problem as part of Inspect and Adapt.

Acceptance Criteria

Acceptance Criteria provide the information needed to ensure that a story, feature, or capability is implemented correctly and covers the relevant functionality and NFRs.

Acceptance Test Driven Development

Acceptance Test-Driven Development is a test-first, Agile testing practice synonymous with Behavior-Driven Development (BDD).

Agile is a set of values, principles, and practices for iterative development most notably described by the Agile Manifesto.

Agile Manifesto

The Agile Manifesto is the seminal Agile document describing the four values and twelve principles of Agile software development.

Agile Product Delivery

Agile Product Delivery is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users.

Agile Program Management Office

The Agile Program Management Office (APMO) is an organizational function responsible for facilitating the Lean Portfolio Management process and fostering operational excellence and lean governance as part of a Lean-Agile transformation.

Agile Release Train (ART)

The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.

Agile Teams

In SAFe, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box.

Architect Sync

The Architect Sync is a Solution Train event to ensure consistency in how emerging designs and tradeoffs are managed across the Solution Train, allowing frequent opportunities to steer implementation approaches without becoming a source of delays.

Architectural Runway

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

The ART Sync is an ART event that combines the Product Owner (PO) Sync and Scrum of Scrums (SoS).

Backlog Refinement

Backlog Refinement is an activity held once or twice during the iteration or increment to discuss, estimate, and establish an initial understanding of acceptance criteria for upcoming stories in the team’s backlog.

Baseline Solution Investments (BSIs)

Baseline Solution Investments (BSIs) are those costs incurred by each value stream as it develops, supports, and operates the solutions that deliver current business capabilities.

Batch size is a measure of how much work (the requirements, designs, code, tests, and other work items) is pulled into the system during any given timebox.

Behavior-Driven Development

Behavior-Driven Development (BDD) is a test-first, Agile testing practice that provides built-in quality by defining (and potentially automating) tests before, or as part of, specifying system behavior.

Benefit Hypothesis

The Benefit Hypothesis is the proposed measurable benefit to the end-user or business as part of a feature or capability.

Big Visible Information Radiator (BVIR)

A Big Visible Information Radiator (BVIR) is a graphical display that tracks and communicates critical data at a glance (e.g. burndown charts, program board, build status boards).

Built-In Quality

Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.

Burn-Down (Burn-Up) Chart

Burn-Down and Burn-Up Charts are graphical displays that show work progress versus time.

Business Agility

Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solutions.

Business and Technology

The Business and Technology icon in SAFe describes how functional domains in all parts of the enterprise enable business agility by continuously exploring new ways to apply Lean-Agile principles and practices to their unique contexts.

Business Context

Business Context is a PI Planning agenda item presented by a business owner that describes the current state of the business, shares the portfolio vision, and presents a perspective on how effectively existing solutions are addressing current customer needs.

Business Owners

Business Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.

SAFe’s CALMR approach to DevOps is a mindset that guides ARTs toward achieving continuous value delivery by managing simultaneous advancements in delivery culture, automation, lean flow, measurement, and recovery.

Capabilities

A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.

Capacity Allocation

Capacity Allocation is a lean budgeting guardrail for backlogs that helps balance the backlog of new features, enablers, and technical debt allocated to for upcoming Program Increment (PI).

Committed PI Objectives

The Committed PI Objectives are a set of SMART objectives that are created by each team with the business value assigned by the Business Owners.

Communities of Practice (CoPs)

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Compliance refers to a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously ensuring they meet any regulatory, industry, or other relevant standards.

Confidence Vote

The Confidence Vote is held near the end of PI Planning where the teams vote on their confidence in meeting PI objectives.

Continuous Delivery Pipeline (CDP)

The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end user.

Continuous Deployment (CD)

Continuous Deployment (CD) is the process that takes validated Features in a staging environment and deploys them into the production environment, where they are readied for release.

Continuous Exploration (CE)

Continuous Exploration (CE) is the process that drives innovation and fosters alignment on what should be built by continually exploring market and customer needs, and defining a Vision, Roadmap, and set of Features for a Solution that addresses those needs.

Continuous Integration (CI)

Continuous Integration (CI) is the process of taking features from the Program Backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.

Continuous Learning Culture

The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation.

Core Values

The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

Cost of Delay

Cost of Delay (CoD) represents the money or value that will be lost by delaying or not doing a job for some time and is used in WSJF prioritization.

Customers are the ultimate beneficiaries of the value of the business solutions created and maintained by the portfolio value streams.

Customer Centricity

Customer centricity is a mindset and a way of doing business that focuses on creating positive experiences for the customer through the full set of products and services that the enterprise offers.

Customer Journey Map

A Customer Journey Map illustrates the experiences as a user engages with a company’s operational value stream, products, and services.

Daily Stand-Up

The Daily Stand Up (DSU) is a daily team event where each team member describes what they did yesterday to advance iteration goals, what they are going to work on today to achieve the iteration goals, and any blocks they are encountering in delivering iteration goals.

Decentralized Decision-Making

Decentralized Decision-Making grants decision authority to those closest to the knowledge and information to reduce delays, increase product development flow, and improve the quality of decisions.

Definition of Done

The Definition of Done communicates the completeness for an increment of value and creates a shared understanding of what work was completed as part of an Increment.

To deploy is to migrate a change from a pre-production environment to a production (or operational) environment, where it then awaits release.

Design Thinking

Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable over their lifecycle.

Develop on Cadence

Develop on Cadence is a coordinated set of practices that support Agile Teams by providing a reliable series of events and activities that occur on a regular, predictable schedule.

Development Value Streams

Development value streams (DVS) are the sequence of activities needed to convert a business hypothesis into a digitally-enabled Solution. Examples include designing a medical device or geophysical satellite, or developing and deploying a software application, SaaS system, or an e-commerce web site.

DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution.

Empathy Map

An Empathy Map is a design thinking tool that helps teams develop deep, shared understanding for their customers.

An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. Enablers are captured in the various backlogs and occur throughout the Framework.

The Enterprise represents the business entity to which each SAFe portfolio belongs.

Enterprise Architect

The Enterprise Architect establishes a technology strategy and roadmap that enables a portfolio to support current and future business capabilities.

Enterprise Solution Delivery

The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated software applications, networks, and cyber-physical systems.

Epic Hypothesis Statement

The Epic Hypothesis Statement captures, organizes, and communicates critical information about an epic.

Epic Owners

Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They collaboratively define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.

An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval by Lean Portfolio Management (LPM) before implementation.

Essential SAFe

Essential SAFe contains the minimal set of roles, events, and artifacts required to continuously deliver business solutions via an Agile Release Train (ART) as a Team of Agile Teams.

Estimating Poker

Estimating Poker is a collaborative technique for relatively estimating the size of stories, features, and WSJF in SAFe.

Extreme Programming

Extreme Programming (XP) is a set of Agile software engineering practices that improves software quality and responsiveness to changing customer requirements developed primarily by Kent Beck.

A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).

Final Plan Review

In the Final Plan Review activity of PI planning, teams present the final plans (PI objectives, load, risks) for communication to the ART and acceptance by the Business Owners.

The Foundation contains the supporting principles, values, mindset, implementation guidance, and leadership roles needed to deliver value successfully at scale.

Full SAFe is the most comprehensive configuration, including all seven core competencies needed for business agility.

Gemba is the place where the work is performed and where teams can observe how stakeholders execute the steps and specific activities in their operational value streams to better identify opportunities for relentless improvement.

Hackathons are innovation events where team members can work on whatever they want, with whomever they want, so long as the work reflects the mission of the company and they demo their work to others at the end of the Hackathon.

Innovation and Planning Iteration

The Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

Inspect & Adapt (I&A)

The Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.

Integration Point

An Integration Point creates a ‘pull event’ that pulls the various solution elements into an integrated whole that helps stakeholders assure that the evolving solution address real and future business needs

Investment Horizons

Investment Horizons highlight spending allocations for solutions that are created by the value streams that help value stream owners and fiduciaries make more informed investment decisions and aligns the portfolio with strategic themes while promoting overall health and growth.

Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. In SAFe, iterations are typically one or two weeks in length, with two being the most common.

Iteration Execution

Iteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.

Iteration Goals

Iteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.

Iteration Planning

Iteration Planning is an event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes the work as a set of committed Iteration Goals.

Iteration Retrospective

The Iteration Retrospective is a regular event where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

Iteration Review

The Iteration Review is a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress, and then adjusts its backlog for the next iteration.

Knowledge Worker

Knowledge Workers are people who have the skill, expertise, and education needed to solve complex problems in their domain of concern.

Large Solution SAFe

Large Solution SAFe describes additional roles, practices, and guidance to build and evolve the world’s largest applications, networks, and cyber-physical systems.

Lead Time is the time it takes from when the work was done in the previous step until it’s done in the current step.

Lean is a body of knowledge and set of practices to improve efficiency and effectiveness by reducing delays and eliminating non-value-added activities.

Lean Budget Guardrails

Lean Budget Guardrails describe the policies and practices for budgeting, spending, and governance for a specific portfolio.

Lean Budgets

Lean Budgets is a Lean-Agile approach to financial governance which increases throughput and productivity by reducing the overhead and costs associated with project cost accounting.

Lean Business Case

A Lean Business Case (LBC) is a light-weight approach to describing epics, including their MVPs and projected business value.

Lean Governance

Lean Governance is one dimension of Lean Portfolio Management that supports oversight and decision-making of spending, audit and compliance, forecasting expenses, and measurement.

Lean Portfolio Management

The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.

Lean Quality Management System (QMS)

A Quality Management System (QMS) dictates practices, policies, and procedures needed to confirm safety and efficacy. SAFe organizations move from traditional to Lean QMS governance.

Lean User Experience (Lean UX)

Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.

Lean-Agile Center of Excellence

The Lean-Agile Center of Excellence (LACE) is a small team of people dedicated to implementing the SAFe Lean-Agile way of working.

Lean-Agile Leadership

The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential.

Lean-Agile Mindset

The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices.

Lean-Agile Principles

SAFe is based on ten immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe.

Little’s Law

Little’s Law is the law of queuing theory and states that the average wait time for service from a system equals the ratio of the average queue length divided by the average processing rate.

Measure and Grow

Measure and Grow is the way portfolios evaluate their progress towards business agility and determine their next improvement steps.

Metrics are agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, ART, and Agile team’s business and technical objectives.

Milestones are used to track progress toward a specific goal or event. There are three types of SAFe milestones: Program Increment (PI), fixed-date, and learning milestones.

Minimum Marketable Feature

The Minimum Marketable Feature (MMF) is the minimum functionality that the teams can build to learn whether the feature’s benefit hypothesis is valid or not.

Minimum Viable Product

In SAFe, a Minimum Viable Product (MVP) is an early and minimal version of a new product or business solution that is used to prove or disprove the epic hypothesis. As opposed to storyboards, prototypes, mockups, wireframes, and other exploratory techniques, the MVP is an actual product used by real customers to generate validated learning.

Model-Based Systems Engineering (MBSE)

Model-Based Systems Engineering (MBSE) is the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders, while significantly reducing or eliminating dependence on traditional documents.

Modified Fibonacci Sequence

A Modified Fibonacci Sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is used during relative estimating to reflect the inherent uncertainty as the size of the job being estimated gets bigger.

Nonfunctional Requirements (NFRs)

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.

Objectives and Key Results

In SAFe, Objectives and Key Results (OKRs) can be used to define, organize, and communicate critical information about a strategic theme and track its progress through concrete, specific, and measurable actions.

Operational Value Streams

Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service.

Organizational Agility

The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities.

Organizational Change Management

Organizational Change Management is a collective term for all approaches to prepare, support, and help individuals, teams, and organizations in making organizational change.

Pareto Analysis

Pareto Analysis is a technique used during an Inspect & Adapt event to narrow down the number of actions that produce the most significant overall effect.

Participatory Budgeting

Participatory Budgeting (PB) is the process that Lean Portfolio Management (LPM) uses to allocate the total portfolio budget to its value streams.

Personas are fictional consumers and/or users derived from customer research that drive a customer-centric approach to product development.

Phase Gates are traditional governance milestones that are replaced in SAFe by milestones based on objective evaluation of working systems.

PI Objectives

Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).

Plan-Do-Check-Adjust

Plan-Do-Check-Adjust (PDCA) is an iterative, four-step method used for controlling variability and making adjustments in response to feedback during product development.

A SAFe portfolio aligns strategy to execution via a collection of development value streams. Operating under a common governance model, each value stream provides one or more solutions the enterprise needs to accomplish its business mission.

Portfolio Backlog

The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.

Portfolio Canvas

The Portfolio Canvas defines the development value streams that are included in a SAFe portfolio, the value propositions and the solutions they deliver, the customers they serve, the budgets allocated to each value stream, and other key activities and events required to achieve the portfolio vision.

Portfolio Kanban

The Portfolio Kanban system is a method to visualize and manage the flow of portfolio Epics, from ideation through analysis, implementation, and completion.

Portfolio SAFe

Portfolio SAFe aligns strategy with execution and organizes solution development around the flow of value through one or more value streams.

Portfolio Vision

The Portfolio Vision is a description of the future state of a portfolio’s Value Streams and Solutions and describes how they will cooperate to achieve the portfolio’s objectives and the broader aim of the Enterprise.

Pre-and Post-PI Planning

Pre– and Post–Program Increment (PI) Planning events are used to prepare for, and follow up after, PI Planning for Agile Release Trains (ARTs) and Suppliers in a Solution Train.

Problem-Solving Workshop

The Problem Solving Workshop is part of the Inspect and Adapt (I&A) event and is a structured approach to finding the root cause of systemic problems.

Product Management

Product Management is responsible for defining desirable, viable, feasible, and sustainable solutions that meet customer needs and for supporting development across the entire product life cycle.

Product Owner (PO)

The Product Owner (PO) is a member of the Agile Team who is responsible for maximizing the value delivered by the team and ensuring that the Team Backlog is aligned with customer and stakeholder needs.

Product Owner (PO) Sync

The PO Sync is an ART event to get visibility into how well the ART is progressing toward meeting its PI objectives, to discuss problems or opportunities with feature development, and to assess any scope adjustments.

Program Backlog

The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.

Program Board

The Program Board highlights the PI’s feature delivery dates, feature dependencies among teams, and relevant milestones.

Program Increment (PI)

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increment (PI) Planning

Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.

Program Kanban

The Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.

Program Predictability Measure

The Program Predictability Measure summarizes the planned vs. actual business values for all the teams on the ART and is a key indicator of the ART’s performance and reliability.

Program Risks

Program Risks are identified by the teams during PI Planning and represent risks and impediments that could impact their ability to meet their objectives.

Refactoring

Refactoring is the activity of improving the internal structure or operation of a code or component without changing its external behavior.

Relative Estimation

Relative Estimation compares jobs to one another to quickly estimate their size and value.

To release is to make functionality that has been deployed to a production (or operational) environment available for use by a defined set of end-users or systems.

Release on Demand

Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand.

Release Train Engineer (RTE)

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Relentless Improvement

Relentless Improvement is the fourth pillar of the SAFe House of Lean and encourages learning and growth through continuous reflection and process enhancements.

The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon.

ROAMing Risks

Risk ROAMing is a PI planning activity where program risks raised by teams are addressed in a broader management context.

Root Cause Analysis

A Root Cause Analysis applies a set of problem-solving tools to identify the actual causes of a problem as part of the Inspect and Adapt event.

SAFe Big Picture (BP)

The SAFe Big Picture (BP) is a visual representation of the framework’s primary roles, activities, and artifacts used to access SAFe articles through its clickable icons when viewed from scaledagileframework.com

SAFe for Government

SAFe for Government is a set of success patterns that help public sector organizations implement Lean-Agile practices in a government context.

SAFe for Lean Enterprises

SAFe for Lean Enterprises is the world’s leading framework for business agility. SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality.

The SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe.

SAFe Lean Startup Cycle

The SAFe Lean Startup cycle is a highly iterative build-measure-learn cycle for product innovation and strategic investments. This strategy for implementing epics provides the economic and strategic advantages of a Lean startup by managing investment and risk incrementally while leveraging the flow and visibility benefits of SAFe.

SAFe Program Consultants (SPCs)

Certified SAFe® Program Consultants (SPCs) are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. SPCs come from numerous internal or external roles, including business and technology leaders, portfolio/program/project managers, process leads, architects, analysts, and consultants.

Scrum Master

SAFe Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

Scrum of Scrums

The Scrum of Scrums (SoS) is an ART event that helps coordinate ART dependencies and provides visibility into progress and impediments.

SAFe ScrumXP is an Agile Team method used by Agile Release Trains (ARTs) to plan, execute, retrospect, and deliver customer value in a short time box. It combines the power of Scrum with Extreme Programming (XP) practices.

Set-Based Design

Set-Based Design (SBD) is a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.

Shared Services

Shared Services represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.

Silos are functionally-aligned organizational constructs that locally optimize for specialists with policies and procedures that ensure repeatable, efficient operations within the functional unit without understanding the larger flow of value across functional units.

Each development value stream develops one or more Solutions, which are products, services, or systems delivered to the customer, whether internal or external to the Enterprise.

Solution Architect/Engineering

Solution Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision across a Solution Train to help ensure the system or Solution under development is fit for its intended purpose.

Solution Backlog

The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Solution Context

Solution Context identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

Solution Demo

The Solution Demo integrates the development efforts from all ARTs and suppliers on the Solution Train every PI and makes them visible to Customers and other stakeholders for evaluation and feedback.

Solution Intent

Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, and functional and nonfunctional tests; and traceability.

Solution Management

Solution Management is responsible for defining and supporting the building of desirable, feasible, viable and sustainable large scale business solutions that meet customer needs over time.

Solution Train

The Solution Train is the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI).

Solution Train Engineer (STE)

The Solution Train Engineer (STE) is a servant leader and coach for the Solution Train, facilitating and guiding the work of all ARTs and Suppliers in the Value Stream.

Spanning Palette

The Spanning Palette contains various roles and artifacts that may apply to a specific team, program, large solution, or portfolio context.

A Spike is a type of exploration Enabler Story that gains the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

Sprint is a term that comes from the Scrum method and is synonymous with the term Iteration in SAFe.

Stories are short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration.

A Story Map is a design thinking technique that organizes a sequence of stories according to the tasks a user needs to accomplish their goal.

Story Point

A Story Point is a singular number used in relative estimating that represents a combination of quantities: volume, complexity, knowledge, and uncertainty.

Strategic Themes

Strategic Themes are differentiating business objectives that connect a portfolio to the strategy of the Enterprise. They influence portfolio strategy and provide business context for portfolio decision-making.

Sunk Costs refers to money already spent, which should be ignored when making future investment decisions to pivot effectively.

A Supplier is an internal or external organization that develops and delivers components, subsystems, or services that help Solution Trains and Agile Release Trains provide Solutions to their Customers.

SWOT Analysis

SWOT Analysis is a strategic planning technique used to identify strengths, weaknesses, opportunities, and threats related to the current business situation as part of a SAFe portfolio vision.

System Architect/Engineering

System Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.

System Demo

The System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).

System Team

The System Team is a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.

Systems Thinking

Systems Thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.

Team and Technical Agility

The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers.

Team Backlog

The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.

Team Kanban

Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

Team Topologies

Team Topologies define four organization types that provide a clear model for organizing Agile teams and ARTs.

Technical Debt

Technical Debt reflects the implied cost and accumulating interest of future work that is commonly caused by knowingly or unknowingly choosing a suboptimal or incomplete solution.

Test-Driven Development

Test-Driven Development (TDD) is a mindset and practice that involves building and executing tests before implementing the code or a component of a system.

TOWs Analysis

TOWS Analysis is used in conjunction with a SWOT analysis to help identify strategic options to create a better future state as part of a SAFe portfolio vision.

U-curve Optimization

The U-curve Optimization for batch size determines the optimal batch size by balancing transaction costs and holding costs.

Uncommitted Objectives

Uncommitted Objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictability measure. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective.

Value represents the benefits an enterprise delivers to its customers and stakeholders and appears in different contexts in SAFe.

Value Stream Coordination

Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams.

Value Stream Identification

Value Stream Identification is an activity that portfolios use to identify development value streams and the operational value streams they support.

Value Stream KPIs

Value Stream Key Performance Indicators (KPIs) are the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes.

Value Stream Management (VSM)

Value Stream Management is a leadership and technical discipline that enables maximum flow of business value through the end-to-end solution delivery life cycle.

Value Stream Mapping

Value Stream Mapping is an essential tool to improve the flow of value across the continuous delivery pipeline by providing the visibility needed to identify bottlenecks and problem areas to flow that cause delays.

Value Streams

Value Streams represent the series of steps that an organization uses to implement Solutions that provide a continuous flow of value to a customer.

Velocity is equal to the sum of the points for all the completed stories that met their Definition of Done (DoD).

The Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.

Weighted Shortest Job First (WSJF)

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (for example, Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by the job duration.

Work in Process

Work in Process (WIP) represents partially completed work. Having too much WIP confuses priorities, causes frequent context switching, and increases overhead.

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.

A Complete Guide to SAFe Feature for Scaling Agile

Home Blog Agile A Complete Guide to SAFe Feature for Scaling Agile

The Scaled Agile Framework has gained considerable popularity in current years for its ability to help organizations scale their Agile practices across the enterprise. SAFe®̥ features and SAFe®̥ capabilities support the implementation of Agile at scale, including Agile Release Trains, PI (Program Increment) Planning, Portfolio Management, and Lean-Agile Leadership.

These Scaled Agile features enable organizations to align their teams and processes around a common vision, foster collaboration and communication and deliver high-quality products and services to customers faster. Additionally, SAFe® Epics and Features provide a structured approach to product management, enabling organizations to prioritize work based on business value and customer needs. The training courses equip professionals with the skills to implement SAFe®̥ practices in their organizations, drive innovation, and achieve business agility. Browse for Agile training courses crucial for professionals looking to adopt Agile methodologies and practices in their organizations.

What are Features in SAFe®?

SAFe® (Scaled Agile Framework) is a methodology for implementing agile practices at scale in larger organizations. In SAFe®, features refer to a unit of functionality that provides business value to the customer. Features are typically defined and prioritized based on their importance to the business and customer needs.

In SAFe®, features are grouped together into a feature backlog, which is a prioritized list of features that need to be implemented. The feature backlog is used to plan and prioritize work in SAFe® and is continually refined based on feedback and changing business needs.

Features are typically broken down into smaller pieces of work called user stories, which are more detailed descriptions of the functionality that is needed to implement the feature. User stories are used to plan and estimate the work required to implement the feature and are typically tracked in a separate backlog called the user story backlog.

Features are a central concept in SAFe®, and they are used to drive the development process and ensure that the team is delivering business value to the customer. By breaking down work into features and user stories, teams can work more efficiently and effectively, and deliver high-quality software that meets the needs of the business and its customers.  Scaled agile framework courses  can teach you how to define, prioritize, and deliver features in SAFe®

Types of SAFe® Features

SAFe® (Scaled Agile Framework) features are designed to help organizations implement and scale Agile practices in a structured and efficient manner. These features include Agile Release Trains, Program Increments, Lean Portfolio Management, Continuous Integration/Deployment, DevOps, and Agile Teams, which work together to deliver value to customers and improve business outcomes.

SAFe® (Scaled Agile Framework) methodology includes three types of features: business features, architectural features, and enabler features.

• Business features provide high-level descriptions of business functionality that provide value to the customer. They represent the customer's needs and are used to prioritize the work of development teams. Business features are a critical input to the portfolio and program level planning, helping organizations to focus on delivering the highest value to the customer.
• Architectural features are technical descriptions of the system or solution functionality that support business features. They provide guidance for the design and implementation of the system or solution, ensuring that it is scalable, maintainable, and secure. Architectural features are a critical input to the solution level planning, helping organizations to develop a well-architected solution that meets the business requirements.
• Enabler features are the smallest pieces of work required to implement an architectural or business feature. They are often technical in nature and help to remove technical impediments that may slow down the development process. Enabler features are a critical input to the program and team level planning, helping development teams to identify the technical dependencies of their work and to plan accordingly.

Understanding these three types of features is essential to implementing SAFe® successfully and delivering value to the customer. By leveraging these features, organizations can manage and deliver value in a more efficient and effective manner.

• Discovering and Describing Features:  This type of feature is focused on identifying and understanding customer needs and describing them in a clear and concise manner. Examples of discovering and describing features include User Stories, Epics, and Business Requirements.
• Creating and Managing Features : This type of feature helps organizations create and manage a backlog of features that need to be developed to deliver value to customers. Examples of creating and managing features include Backlog Management, Iteration Planning, and Program Backlogs.
• Prioritizing Features : This type of feature helps organizations prioritize the backlog of features based on customer needs, business value, and other factors. Examples of prioritizing features include WSJF (Weighted Shortest Job First), Cost of Delay, and Value Stream Mapping .
• Estimating Features : This type of feature helps organizations estimate the time and effort required to develop each feature, which helps with planning and resource allocation. Examples of estimating features include Story Points, Ideal Days, and T-Shirt Sizing.
• Accepting Features : This type of feature helps organizations ensure that the features developed meet the customer's needs and business requirements. Examples of accepting features include Acceptance Criteria, Definition of Done, and Acceptance Testing.

Benefits of SAFe® Features

SAFe® (Scaled Agile Framework) offers benefits such as scalability, collaboration, and transparency, enabling organizations to achieve agility at scale, work more effectively, and make informed decisions.

Below are some benefits of SAFe® features:

• Improved collaboration and communication: SAFe® features encourage collaboration and communication between teams, allowing for a more cohesive and streamlined development process.
• Better alignment with customer needs: By utilizing SAFe® features to discover and describe customer needs, organizations can ensure that their solutions are aligned with customer needs and business goals, resulting in increased customer satisfaction and improved ROI.
• Faster time-to-market: SAFe® features allow for the efficient management of development efforts, breaking down larger features into smaller, more manageable pieces that can be delivered faster.
• Improved quality: SAFe® features provide tools and processes for acceptance testing and quality assurance, ensuring that features meet the required standards and are of high quality.
• Increased flexibility: SAFe® features provide a flexible framework that can be customized to suit the unique needs of each organization, enabling organizations to respond to changing market conditions and customer needs more quickly.

Overall, leveraging SAFe® features can result in a more efficient and effective Agile development process, resulting in improved customer satisfaction, increased revenue, and a competitive advantage in the marketplace.

How to Use Features of SAFe®?

SAFe® provides a set of practices, roles, and tools to enable organizations to scale agile methodologies and deliver value to customers faster. Here are some steps to use the features of SAFe®:

• Understand the SAFe® methodology: Before you start using the features of SAFe®, it's essential to have a good understanding of the methodology. You can read the SAFe® website, attend leading SAFe® courses or hire a SAFe® coach to help you with this.
• Identify the SAFe® features that align with your goals: SAFe® offers a wide range of features, including Agile Release Trains (ARTs), Lean Portfolio Management, Agile Product Delivery, Continuous Integration and Continuous Deployment (CI/CD), DevOps, and more. Identify the features that align with your goals and needs.
• Create an implementation plan: Once you've identified the SAFe® features you want to use, create an implementation plan. This plan should outline the steps you'll take to introduce the features into your organization, the timeline for implementation, and any resources you'll need.
• Train your team: SAFe® is a team-based approach, so it's crucial to train your team on the methodology and the features you're implementing. Provide SAFe® Scrum Master training course to your team and ensure everyone understands the SAFe® principles, practices, and tools.
• Implement SAFe® features gradually: SAFe® features are complex, and it's important to implement them gradually to avoid overwhelming your team. Start with a few features, test them, and make adjustments as necessary before adding more features.
• Monitor and evaluate progress: Regularly monitor and evaluate your SAFe® implementation to ensure it's achieving the desired results. Use metrics such as cycle time, lead time, and customer satisfaction to measure progress.
• Continuously improve: SAFe® is an iterative process, and continuous improvement is key to its success. Regularly evaluate and adjust your SAFe® implementation to ensure you're delivering value to your customers and achieving your business goals.

In summary, to use SAFe® features, you need to understand the methodology, identify the features that align with your goals, create an implementation plan, train your team, implement the features gradually, monitor progress, and continuously improve your implementation.

Examine the top trending  Agile Category Courses

What are Capabilities in SAFe®?

In SAFe® (Scaled Agile Framework), capabilities refer to a higher-level portfolio management construct that represents the ability of the organization to deliver value to its customers. Capabilities are a set of related features that work together to achieve a specific business outcome or goal.

Capabilities are used to plan and prioritize work at the portfolio level, and they are typically tied to specific business initiatives or objectives. They are also used to align the work of multiple Agile Release Trains (ARTs) and teams, ensuring that they are all working towards the same overall goal.

In SAFe®, capabilities are typically broken down into smaller pieces of work called epics, which are larger than user stories but smaller than capabilities. Epics are used to describe the scope of the work required to achieve a capability, and they are used to plan and prioritize work at the program level.

By breaking down work into capabilities, epics, and user stories, SAFe® provides a hierarchical structure for planning and delivering value to the customer. This structure allows organizations to align their work with their strategic goals and ensures that teams are working towards a common purpose, resulting in increased efficiency and better business outcomes.

Splitting Features and Capabilities

This type of feature helps organizations break down larger features and capabilities into smaller, more manageable pieces that can be developed and delivered more efficiently. Examples of splitting features and capabilities include Spikes, MVPs (Minimum Viable Products), and Story Mapping.

A Framework for Success

In conclusion, SAFe® provides a robust framework for organizations looking to scale agile practices and manage large-scale software development projects . Its features and capabilities are designed to align an organization's strategy with its development efforts, promote collaboration and communication among teams, and deliver value to customers faster. By implementing SAFe® gradually, training teams, and monitoring progress regularly, organizations can successfully adopt SAFe® and enjoy its benefits of increased efficiency, faster time-to-market, and improved customer satisfaction. SAFe® is a powerful tool for organizations looking to stay competitive in today's fast-paced software development landscape.

Frequently Asked Questions

SAFe®, or the Scaled Agile Framework, has four levels, each providing increasing degrees of organization and coordination:

• Essential SAFe®: provides the foundation for scaling agile across an organization.
• Large Solution SAFe®: coordinates multiple agile teams working on a common solution.
• Portfolio SAFe®: aligns an organization's portfolio of initiatives and programs with its overall business strategy.
• Full SAFe®: provides a comprehensive approach to scaling agile across an organization, including coordinating multiple value streams and managing large and complex solutions.

In SAFe®, a feature is a small, self-contained functionality that delivers value to the customer. A feature typically takes a few weeks to a few months to implement and is developed by a cross-functional agile team. The exact size of a feature can vary depending on the context and complexity of the solution being developed. However, in general, a feature is larger than a user story and smaller than an epic. It is typically sized to be deliverable within a single Program Increment (PI) and is aligned with the organization's overall business and customer needs.

In SAFe®, a feature team is a cross-functional and self-organizing agile team that is responsible for delivering a feature or set of features that provide value to the customer.

The feature team typically includes all the skills and expertise needed to design, develop, test, and deploy the feature, and is composed of full-time members who work together in a collaborative and iterative manner.

Feature teams are an important aspect of SAFe®, as they enable organizations to deliver high-quality and valuable features to customers on a regular basis, and are a key component of the Agile Release Train (ART) which is a primary vehicle for delivering value in SAFe®.

A feature in SAFe® is a high-level requirement that describes a valuable functionality or capability that the software system should provide to its users. An example of a feature in SAFe® could be "Streamlined checkout process for improved user experience" for an e-commerce website. This feature would involve multiple user stories or backlog items, such as saving shipping and payment information, providing real-time shipping cost estimates, and implementing a clear interface for entering payment information. The development team would follow SAFe®'s steps, including breaking down the feature, prioritizing components, estimating time, and iterating on the design and implementation until it meets quality standards.

Epics in SAFe® (Scaled Agile Framework) are large initiatives or projects that cannot be completed within a single iteration and require multiple teams to work collaboratively to achieve the desired outcome. They are similar to features, but at a higher level of abstraction. Epics are used to provide a strategic roadmap for the development team and ensure that everyone is working towards a common goal. They are broken down into smaller, more manageable pieces called features, which can then be prioritized and scheduled for delivery over multiple iterations. Epics are typically defined by the product owner and are used to align the development team with the overall business objectives.

Rajesh Bhagia

Rajesh Bhagia is experienced campaigner in Lamp technologies and has 10 years of experience in Project Management. He has worked in Multinational companies and has handled small to very complex projects single-handedly. He started his career as Junior Programmer and has evolved in different positions including Project Manager of Projects in E-commerce Portals. Currently, he is handling one of the largest project in E-commerce Domain in MNC company which deals in nearly 9.5 million SKU's.

In his role as Project Manager at MNC company, Rajesh fosters an environment of teamwork and ensures that strategy is clearly defined while overseeing performance and maintaining morale. His strong communication and client service skills enhance his process-driven management philosophy.

Rajesh is a certified Zend Professional and has developed a flair for implementing PMP Knowledge Areas in daily work schedules. He has well understood the importance of these process and considers that using the knowledge Areas efficiently and correctly can turn projects to success. He also writes articles/blogs on Technology and Management

Avail your free 1:1 mentorship session.

Something went wrong

Upcoming Agile Management Batches & Dates