when is a feature hypothesis fully evaluated safe

Preparing Features for PI Planning - Part Three

A lot of work goes into the continuous refinement of a product’s backlog. This is true as much for Feature Backlogs as it is for Story backlogs. When using SAF e® if it often seems that too much work goes into preparing the Features and getting them ready for PI Planning. This series of blogs focusses on various topics concerned with preparing Features for PI Planning:

• Just say no to waterfall thinking
• The seven deadly sins of Feature Preparation
• What does it mean to be Feature ready? (this article)
• Some practical tips to avoid waterfalling Features

Download the Feature State Cards that go with this article below

So what does it mean for a Feature to be “Ready”? And just as importantly when do they need to be “Ready”?

As many people have observed ( Read Mike Cohn’s article ) Definition of Ready can be a dangerous thing leading to waterfall behavior and strict hand-overs between Product Owners and their teams. In many cases teams would be better off not having one as it often stops them from working on the most important Feature because they believe it’s someone else’s job to get it ready. But keeping this in mind, what would make a suitable definition of ready for a Feature?

Personally, we’ve always been fond of Roman Pichler’s simple definition that to be ready a backlog item should be clear, feasible and testable. This applies as well to Features as it does to Stories, and provides the first ready test for any Product Manager to apply to their Features. If they don’t feel it is clear, feasible or testable they shouldn’t be letting it anywhere near the top of their backlog and into their next PI .

For Features it is worthwhile taking a look at what each of these means.

• Clear – It is clear what the feature means and how it will benefit the customers, users and other stakeholders. Basically, the Product Management / Ownership community can readily explain what the Feature means and explain its intricacies to the development team. If they don’t have the knowledge to explain the Feature and answer the development team’s questions then they are not ready, and by implication neither is the Feature.
• Feasible – it is technically feasible to implement the Feature. This implies that the estimate is accurate enough for prioritization purposes (so the Feature doesn’t have a false position in the backlog), and is small enough to be completed within a Program Increment ( PI ). If there is too much uncertainty or technical risk related to the Feature then an enabler Feature should be broken out to directly address the issues. If the it is not easily understood how the Feature will implemented then the Feature is not ready.
• Testable – it is understood how the Feature will be tested. Not just how its Storied will be tested but also how the Feature as a whole will be tested. In particular it is useful to know whether or not any new or unique types of testing are required. If the Feature is not testable then it is not doable, and therefore not ready.

It is also critically important that any Features selected conform to Bill Wake’s incredibly popular INVEST acronym, which describes the properties of a well-formed backlog items. An acronym that applies as much, if not more, to Features as it does to Stories.

Again, it is worth taking a look at how thinking INVEST can help us to prepare our Features properly.

• Independent – all Features should be thought of as independent from all other Features, particularly when prioritizing and preparing them prior to a PI planning meeting (i.e. getting them Ready). There may be a natural order to the Features in that Feature 2 doesn’t make a lot of sense if Feature 1 isn’t in place. This doesn’t imply dependency as we could implement Feature 2 before Feature 1 if we wanted to, but that doing them in this order wouldn’t make any business sense.

Sometimes Features will require the same changes to be made to the codebase or even contain the same Stories. This doesn’t make the Features dependent on each other but can 1) make them more challenging to implement simultaneously and 2) lead to changes to their estimates as the overlapping Features are implemented. This potential overlap is one of the reasons we like to do collaborative PI planning with the whole team. By simultaneously planning the work on a set of Features the teams can discover and collaborate to exploit any overlaps helping the team-of-teams to deliver even more Features.

• Negotiable – This one is the big one as not only is the priority of the Feature negotiable so are its extent (the number of stories it involves) and its acceptance criteria. PI planning is not just about planning but also negotiating the scope and extent of the Features being planned.
• Valuable – it should go without saying that all Features should have clear value to the business and benefit for the users and other stakeholders.
• Estimable – If the Feature can’t be estimated then it can’t be prioritized. You cannot prioritize a backlog on value alone. Note: the estimates will change over time as Features can overlap (see Independent above) and need to be estimated against the current state and capabilities of the system – an estimate which may well change every PI .
• Sized Appropriately / Small – All Features should be sized appropriately for their position in the Backlog. If the Feature is under consideration for implementation in the next PI then it needs to be small enough to readily fit in the PI . If it isn’t it will need to be sliced. If the Feature is not going to be implemented until a subsequent time-box then it can be any size it likes. If you’re never going to do it then who cares how big it is
• Testable – see the discussion above.

Taking all of this into account, and focusing on what it means for a Feature to be ready to be used as input into PI planning we have put together this simple checklist.

This checklist, as shown in Figure 1, is also available as one of a set of 6 mini-checklist cards that together define the lifecycle of a Feature.

Figure 1: Checklist cards for Feature Evolution

If things go to plan future blogs will further explore the lifecycle of a Feature and the other checklists, but the full set of cards are available for download now below, along with an editable copy of the Ready checklist. Complete the form below to receive the one page PDF of the Feature cards.

In the final blog in this series we will provide some practical advice on activities you can do to get your Features ready for PI planning without falling prey to the seven sins of feature preparation and back into waterfall behavior. Find it here: Some practical tips to avoid waterfalling Features

More Great Agile Content from Ivar Jacobson International:

• How Many Features do you need for PI Planning
• WSJF & Feature Slicing
• All about the PI Planning Management Review & Problem Solving
• Secrets of Dispersed PI Planning
• Estimating in Story Points

Upcoming Training

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

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 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…

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…

Name (required)

Email (required)

Privacy Preference Center

Privacy preferences.

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

What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget? —Eric Ries

Lean UX design extends the traditional UX role beyond merely executing design elements and anticipating how users might interact with a system. Instead, it encourages a far more comprehensive view of why a Feature exists, the functionality required to implement it, and the benefits it delivers. By getting immediate feedback to understand if the system will meet the real business objectives, Lean UX provides a closed-loop system for defining and measuring value.

Generally, UX represents a user’s perceptions of a system—ease of use, utility, and the effectiveness of the user interface (UI). UX design focuses on building systems that demonstrate a deep understanding of end users. It takes into account what users need and wants while making allowances for the user’s context and limitations.

A common problem, when using Agile methods, is how best to incorporate UX design into a rapid Iteration cycle that results in a full-stack implementation of the new functionality. When teams attempt to resolve complex and seemingly subjective user interactions, while simultaneously trying to develop incremental deliverables, they can often churn through many designs, which can become a source of frustration with Agile.

Fortunately, the  Lean UX  movement addresses this by using Agile development with Lean Startup  implementation approaches. The mindset, principles, and practices of SAFe reflect this thinking. This process often begins with the Lean Startup Cycle described in the  Epic  article and continues with the development of Features and Capabilities  using a Lean UX process described here.

As a result, Agile teams and Agile Release Trains (ARTs) can leverage a common strategy to generate rapid development, fast feedback, and a holistic user experience that delights users.

The Lean UX Process

In Lean UX , Gothelf and Seiden [2] describe a model that we have adapted to our context, as Figure 1 illustrates. It follows SAFe’s Continuous Delivery Pipeline and focuses more on team-level activities.

Benefit Hypothesis

The Lean UX approach starts with a benefit hypothesis: Agile teams and UX designers accept the reality that the ‘right answer’ is unknowable up-front. Instead, teams apply Agile methods to avoid Big Design Up-front (BDUF), focusing on creating a hypothesis about the feature’s expected business result, and then they implement and test that hypothesis incrementally.

The SAFe Feature and Benefits matrix (FAB) can be used to capture this hypothesis as it moves through the Continuous Exploration cycle of the Program Kanban :

• Feature  – A short phrase giving a name and context
• Benefit hypothesis  – The proposed measurable benefit to the end user or business

Outcomes are measured in Release on Demand and best done using leading indicators (see Innovation Accounting in [1]) to evaluate how well the new feature meets its benefits hypothesis. For example, “We believe the administrator can add a new user in half the time it took before.”

Collaborative Design

Traditionally, UX design has been an area of specialization. People who have an eye for design, a feel for user interaction, and specialty training were often entirely in charge of the design process. The goal was ‘pixel perfect’ early designs, done in advance of the implementation. Usually, this work was done in silos, apart from the very people who knew the most about the system and its context. Success was measured by how well the implemented user interface complied with the initial UX design. In Lean UX, this changes dramatically:

“Lean UX literally has no time for heroes. The entire concept of design as a hypothesis immediately dethrones notions of heroism; as a designer, you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.” [2]

Continuous Exploration takes the hypothesis and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders – Architects , Customers , Business Owners , Product Owners , and Agile Teams .  This further refines the problem and creates artifacts that clearly express the emerging understanding including personas, empathy maps, and customer experience maps.

Principle #9 – Decentralize decision-making provides additional guidance for the Lean UX process: Agile teams are empowered to do collaborative UX design and implementation, and that significantly improves business outcomes and time-to-market. Moreover, another important goal is to deliver a consistent user experience across various system elements or channels (e.g., mobile, web, kiosk) or even different products from the same company. Making this consistency a reality requires some centralized control (following Principle #9) over certain reusable design assets. A design system [2] is a set of standards that contains whatever UI elements the teams find useful, including:

• Editorial rules, style guides, voice and tone guidelines, naming conventions, standard terms, and abbreviations
• Branding and corporate identity kits, color palettes, usage guidelines for copyrights, logos, trademarks, and other attributions
• UI asset libraries, which include icons and other images, templates, standard layouts, and grids
• UI widgets, which include the design of buttons and other similar elements

These assets are an integral part of the Architectural Runway, which supports decentralized control while recognizing that some design elements need to be centralized. After all, these decisions are infrequent , long-lasting and provide significant economies of scale , as described in Principle #9, Decentralize decision-making.

With a hypothesis and design in place, teams can proceed to implement the functionality in a Minimum Marketable Feature (MMF). The MMF should be the minimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not. By doing this, the ARTs apply SAFe Principle #4 – Build incrementally with fast, integrated learning cycles , to implement and evaluate the feature. Teams may choose to preserve options with Set-Based Design , as they define the initial MMF.

In some cases, early designs could initially be extremely lightweight and not even functional (ex., paper prototypes, low fidelity mockups, simulations, API stubs). In other cases, a vertical thread (full stack) of just a portion of an MMF may be necessary to test the architecture and get fast feedback at a System Demo . However, in some instances, functionality may need to proceed all the way through to deployment and release, where application instrumentation and telemetry [4] provide feedback data from production users.

MMFs are evaluated as part of deploying and releasing (where necessary). There are a variety of ways to determine if the feature delivers the right outcomes. These include:

• Observation – Wherever possible, directly observe the actual usage of the system, it’s an opportunity to understand the user’s context and behaviors.
• User surveys – When direct observation isn’t possible, a simple end-user questionnaire can obtain fast feedback.
• Usage analytics – Lean-Agile teams build analytics right into their applications, which helps validate initial use and provides the application telemetry needed to support a Continuous Delivery model. Application telemetry offers constant operational and user feedback from the deployed system.
• A/B testing – Is a form of statistical hypothesis comparing two samples, which acknowledges that user preferences are unknowable in advance. Recognizing this is truly liberating, eliminating endless arguments between designers and developers—who likely won’t use the system. Teams follow Principle #3 – Assume variability; preserve options to keep design options open as long as possible. And wherever it’s practical and economically feasible, they should implement multiple alternatives for critical user activities. Then they can test those other options with mockups, prototypes, or even full stack implementations. In this latter case, differing versions may be deployed to multiple subsets of users, perhaps sequenced over time and measured via analytics.

In short, measurable results deliver the knowledge teams need to refactor, adjust, redesign—or even pivot to abandon a feature, based solely on objective data and user feedback. Measurement creates a closed-loop Lean UX process that iterates toward a successful outcome, driven by actual evidence of whether a feature fulfills the hypothesis, or not.

Implementing Lean UX in SAFe

Lean UX is different than the traditional, centralized approach to user experience design. The primary difference is how the hypothesis-driven aspects are evaluated by implementing the code, instrumenting where applicable, and gaining the actual user feedback in a staging or production environment. Implementing new designs is primarily the responsibility of the Agile Teams, working in conjunction with Lean UX experts.

Of course, this shift, like so many others with Lean-Agile development, can cause significant changes to the way teams and functions are organized, enabling a continuous flow of value. For more on coordinating and implementing Lean UX —and more specifically how to integrate Lean UX in the PI cycle—read the advanced topic article Lean UX and the Program Increment Lifecycle .

Last update: 27 September 2021

Privacy Overview

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

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

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

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

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

Understanding the Requirements in SAFe

Aman Luthra

As organizations scale up their Agile endeavors, the need to harmonize strategic intent with executable units becomes paramount. This is where SAFe’s structured approach to requirements steps in, facilitating seamless collaboration between business stakeholders, product teams, and development units. From envisioning the big picture to ensuring the tiniest details are aligned, the SAFe framework provides a clear and organized path.

In this blog, we take a deep dive into the layers of the requirements named Epics, Capabilities, Features, Stories, and Enablers and what makes them essential components of the SAFe ecosystem.

In layman term’s, An Epic is an significant solution development initiative.

Epics have a considerable scope and impact, and therefore require the definition of a MVP (Minimum Viable Product) and has to be approved by the Lean Portfolio Management.

We will learn about the definition, approval and implementation of Epics, along with brief explanation of ART and Solution Train epics, which follow a similar pattern. But before we move on to it, we need to keep in mind a couple of points.

Epics are not merely synonyms for Projects and thus SAFe discourages using the project funding model. Secondly, we must understand there are two types of Epics. Business epics deliver value to the business directly, while enabler epics advance and support needs. We will be discussing Enablers in length in this blog.

For epics to reach the beginning of development, they need the stakeholders to agree on their intent and definition. This is crucial because epics involve some of the most significant enterprise investments.

An important part of defining epics is an Epic Hypothesis Statement. It is an template for capturing, organizing and communicating critical information about an epic. Below figure shows a template for the epic hypothesis statement.

Approved epics are made visible, developed and managed through the Portfolio Kanban system, where they go through stages of maturity and changes until they’re approved or rejected. However, we must understand epics needs analysis before they are committed to implementation. Epic Owners take responsibility for the critical collaborations needed for Business Epics, while Enterprise Architects typically guide the Enabler epics that support the technical considerations for business epics.

Creating the Lean Business Case

The Lean Business Case is derived from the result of the epic analysis. Once developed, it is reviewd by the LPM who make a go/no-go decision for the case. Once approved, it is moved into the ready state and is pulled into implementation when capacity and budget is available. The Epic owner splits the epic into features with close working with other teams and helps prioritize these items in their respective backlogs.

Defining MVP and Estimating Costs

The MVP is an early and minimal version of a new product or business Solution used to prove or disprove the epic hypothesis. It is included in the Epic analysis.

It is important for the LPM to understand the investment needed to realize the hypothesis value. This analysis requires a meaningful estimate of the cost of the MVP, and the forecasted cost of the full implementation should the epic hypothesis be proven true.

Considerable strategic efforts often require collaboration with external Suppliers to develop Solutions. The MVP and the anticipated full implementation cost estimates should include internal costs and forecasted external Supplier expenses. The Epic Owner can incrementally refine the total implementation cost as the MVP is built and learning occurs. They should also determine the amount of MVP’s investment with other key stakeholders. This should be sufficient to prove or disprove the hypothesis.

One thing to keep in mind is that epic investments often requires contributions from suppliers, be it internal or external. Supplier cost is also an important factor of estimating costs for the Epic.

Forecasting Duration

While it can be challenging due to its dependence on multiple factors like internal and external durations, it is absolutely necessary to forecast the duration of the Epic to ensure its proper functioning.

Forecasting an epic’s duration requires an understanding of three data points:

• An epic’s estimated size in story points for each affected ART can also be calculated using T-shirt sizes and replacing the cost range with a story point range
• The historical velocity of the impacted ARTs
• The percent (%) capacity allocation that ARTs can dedicate to working on the epic. This allocation typically results from negotiation between Product and Solution Management, Epic Owners, and LPM.

After repeating these calculations for each ART, the Epic Owner can see that some ARTs will likely be ready to release on demand earlier than others. However, the forecasted duration to deliver the entire epic across all ARTs will likely be between six and eight PIs. If this forecast does not align with business needs, negotiations such as adjusting capacity allocations or increasing the budget for suppliers will ensue. The Epic Owner updates the forecasted completion once work begins on the epic.

Implementing Epics

The SAFe Lean startup strategy recommends a highly iterative build-measure-learn cycle for product innovation and strategic investments. This approach 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 (as shown in the below figure)

Gathering the data necessary to prove or disprove the epic hypothesis is highly iterative. These iterations continue until a data-driven result is obtained or the teams consume the entirety of the MVP budget. In general, the result of a proven hypothesis is an MVP suitable for continued investment by the value streams. Otherwise, any further investment requires the creation of a new epic.

Once Epics are approved for implementation, Epic Owners works with Agile Teams to begin the development activities.

ART and Solution Train Epics

Epics sometimes may also originate from ARTs or Solution Trains. They begin as initiatives that warrant LPM attention because of the significant impact to the business. These epics also deserve a lean business case and review through the Portfolio Kanban system.

CAPABILITIES

A Capability is a high-level solution behavior that usually spans multiple ARTs. To facilitate their implementation in a single PI, capabilities are sized and divided into multiple features. For everyone who participates in a SAFe portfolio, these guiding principles help dictate behavior and action.

One must remember that capabilities behave the same way as features, but they are at a higher level of abstraction and support the definition and development of large solution.

Similarities between Capability and Features

As mentioned above, capabilities behave the same way as features and exhibit the same characteristics and practices.

For example:

• Both are described using a phrase and benefit hypothesis
• Both are sized to fit within a PI (they might take multiple ARTs to implement)
• Both are reasoned about and approved using the Solution Train Kanban. The Solution Train Backlog holds approved capabilities
• Both have associated enablers to describe and bring visibility to all the technical work necessary to support the efficient development and delivery of business capabilities
• Both are accepted by Solution Managers, who use the acceptance criteria to determine whether the functionality is fit for purpose

Capabilities may originate in the local context of the solution or occur as a result of splitting portfolio epics that may cut across more than one Value Stream. Another potential source of capabilities is the Solution Context, where some aspects of the environment may require additional solution functionality.

One important point to remember is that capabilities are decomposed which in turn build the features. SAFe provides ten patterns for splitting work as given below:

• Workflow steps
• Business rule variations
• Major effort
• Simple/complex
• Variations in data
• Data methods
• Deferring system qualities
• Use-case scenarios
• Breaking out a spike

The following figure shows splitting a capability into features

A Feature represents solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release Train within a PI.

Just like a capability, every feature includes a benefit hypothesis and acceptance criteria. Also, just like capabilities features are also sized or split as necessary to be delivered by a single Agile Release Train (ART) in a PI. They lend themselves to the Lean UX model to include a definition of the MMF (Minimum Marketable Feature). The MMF helps limit the scope and investment, enhances agility and provides fast feedback.

Discovering and Describing Features

Features are defined using a features and benefits format:

• Feature — a short phrasegiving a name and context
• Benefit hypothesis — the proposed measurable benefit to the end user or business

Features usually provide functionality to multiple user roles, and therefore one must avoid defining features with the user story voice. Also, to avoid confusion later user stories and features should not be described using the same method.

Creating and Managing Features

While features arise are splitting epics, PMs also define features in the local context of the ART in collaboration with POs and other key stakeholders. Just like epic enablers, there are feature enablers too which provide support and infrastructure needed to develop and test the features. These are typically created by the SAs.

Like business features, enabler features may originate from epics or emerge locally at the ART level. Enablers that make it through the Kanban system will be subject to capacity allocation in the ART backlog to ensure enough emphasis on furthering the solution and extending the architectural runway. At each PI boundary, the percentage of resources allocated to new features (or capabilities) versus enablers is estimated to guide the train.

Prioritizing, Estimating and Accepting Features

The WSJF prioritization model is used to sequence features based on the economics of product development flow. Since implementing the right jobs in the right sequence produces the maximum economic benefit. We must remember that prioritizing is critical and thus the underlying importance of this critical process.

Estimation of features supports forecasting value delivery, ensuring prioritization and splitting epics into features and summing their estimates. It usually occurs in the analysis state of the ART Kanban. During analysis, select subject matter experts from the ART engage in exploration activities and preliminary sizing.

Feature acceptance criteria determine whether the implementation is correct and delivers the business benefits. The below figure provides an example:

Product Management is responsible for accepting the features. They use acceptance criteria to determine whether the functionality is implemented correctly and whether nonfunctional requirements are met.

Stories are short descriptions of a small piece of desired functionality written from the user’s perspective. They are implemented by agile teams as small, vertical slices of system functionality that can be completed in a few days or less. They are short, simple descriptions of functionality told from the user’s perspective and written in their language and are the primary artifact used to define system behavior in Agile. Each implements a small, vertical slice of system behavior. Stories provide just enough information for business and technical people to understand the intent.

Just like epics and features, there are user stories and enabler stories. User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.

Stories ares usually driven by splitting features, as shown in the figure below

User Stories

User stories are the primary means of expressing needed functionality. They essentially replace the traditional requirements specification. In some cases, however, they serve as a means to explain and develop system behavior later recorded in specifications supporting compliance, suppliers, traceability, or other needs.

Because they focus on the user as the subject of interest and not the system, user stories are value and customer-centric. To support this, the recommended form of expression is the ‘user-voice form,’ as follows: As a (user role), I want to (activity) so that (business value).

While the user story voice is typical, not every system interacts with an end user. Sometimes the ‘user’ is a device (for example, printer) or a system (for example, transaction server). In these cases, the story can take on the form illustrated in the figure below.

The 3Cs: Card, Conversation and Confirmation

The 3Cs of a story is credited to Ron Jeffries, one of the inventers of XP. They are described below

Card — Captures the user story’s statement of intent using an index card, sticky note, or tool. Index cards provide a physical relationship between the team and the story. The card size physically limits story length and premature suggestions for the specificity of system behavior.

Conversation — Represents a “promise for a conversation” about the story between the team, customer (or the customer’s proxy), the PO (who may be representing the customer), and other stakeholders. The discussion is necessary to determine the more detailed behavior required to implement the intent.

Confirmation — The acceptance criteria provide the information needed to ensure that the story is implemented correctly and covers the relevant functional and NFRs. The below shown figure provides an example. Some teams often use the confirmation section of the story card to write down what they will demo.

Investing and Splitting

Agile teams spend significant time discovering, elaborating, and understanding user stories and writing acceptance tests. Therefore, investing in good user stories, albeit at the last responsible moment, is a worthy effort for the team. Bill Wake coined the acronym INVEST to describe the attributes of a good user story.

Smaller stories allow faster more reliable implementation since small items flow through any system faster, with less variability and reduced risk. Therefore, splitting bigger stories into smaller ones is a mandatory skill for every Agile team. The splits are performed in the same ways using the 10 ways mentioned above in Epics.

Estimating Stories

Agile teams often use ‘estimating poker,’ which combines expert opinion, analogy, and disaggregation to create quick but reliable estimates. Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces. (Note that there are several other methods used as well.)

The rules of estimating poker are:

• Participants include all team members
• Each estimator is given a deck of cards containing the modified Fibonacci sequence
• The PO participates but does not estimate
• The Scrum Master/Team Coach participates but does not estimate unless they are doing actual development work
• For each backlog item to be estimated, the PO reads the story’s description
• Questions are asked and answered
• Each estimator privately selects an estimating card representing their estimate
• All cards are turned over at the same time to avoid bias and to make all estimates visible
• High and low estimators explain their estimates
• After a discussion, each estimator re-estimates by selecting a card
• The estimates will likely converge; if not, the process is repeated

Some amount of preliminary design discussion is appropriate. However, spending too much time on design discussions is often a wasted effort. The real value of estimating poker is agreeing on a story’s scope. It’s also fun!

Velocity and Capacity

The team’s velocity for an iteration is equal to the sum of the points for all the completed stories that met their definition of done (DoD). As the team works together over time, their average velocity (completed story points per iteration) becomes reliable and predictable.

Capacity is the portion of the team’s velocity that is available for any given iteration. Vacations, training, and other events can make team members unavailable to contribute to an iteration’s goals for some portion of the iteration. This decreases the maximum potential velocity for that team for that iteration.

The blog has been mentioning enablers for almost all the requirements discussed. Now we will havea look at what exactly enablers are.

Enablers are backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream. Enablers are captured in backlogs as a type of Epic, Capability, Feature, or Story. They are used primarily for exploration, architecture implementation, refactoring, building infrastructure, and addressing compliance. While their type is unique, they are managed similarly to customer-facing backlog items.

Types of Enablers

Enablers can be used to define any activity that improves the value stream in support of foreseeable business needs. These activities generally fall into one of four categories:

• Exploration — support research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective Solutions and evaluation of alternatives
• Architectural — used to build Architectural Runway, which allows smoother and faster development through the Continuous Delivery Pipeline (CDP)
• Infrastructure — support the creation and optimization of the development and runtime environments that host the systems used to build, validate, deploy, and operate solutions
• Compliance — facilitate managing specific compliance activities, including Verification and Validation (V&V), audits and approvals, and policy automation

Creating and Managing Enablers

Enablers exist throughout SAFe and written and prioritized according to the same rules as their corresponding epics, features, capabilities and stories.

• Enabler Epics — These are written using the ‘epic hypothesis statement’ format, in the same way as business epics. Enabler epics can span multiple Agile Release Trains (ARTs) and PIs and are managed via the Portfolio Backlog and associated Kanban system
• Enabler Features and Capabilities — These are defined by ARTs and Solution Trains and include a short phrase, benefit hypothesis, and acceptance criteria. They must be sized to fit within a single PI
• Enabler Stories — Must fit within Iterations like any story. Although they may not require the user voice format, their acceptance criteria clarify the requirements and support testing.

Written by Aman Luthra

Text to speech