Understanding the Requirements in SAFe
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.
EPICS
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.
Definition
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
- Operations
- Use-case scenarios
- Breaking out a spike
The following figure shows splitting a capability into features
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
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.
ENABLERS
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.
Comments
Post a Comment