What are the stories, features, capabilities, and epics in SAFe?
When you want to express a requirement for functionality in SAFe, you can use stories, features, capabilities and epics. When is each of these used? What level of detail do they contain? And who has content authority for them?
Requirement model
In general, descriptions of new functionality, or updates to existing functionality, start at a high level and get broken down into smaller items as more detail is needed and understood. Not every team using SAFe will use capabilities and epics, but all teams using SAFe should use stories and features, as they are part of the essential levels.
Stories
Stories are created by the agile team who are going to do the work and they are put onto the team backlog. The product owner in that team has content authority over the stories and, as part of that, they prioritise the stories on the team backlog. All stories must be small enough to fit into a single iteration for a single agile team. There are two categories of stories, user stories and enabler stories.
User Stories
These describe the required functionality from the perspective of the user, using the user voice statement format, which is:
As a <user>
I want <function>
So that <purpose>
This boils down to the ‘who?’, ‘what?’ and ‘why?’ of the change.
In addition to the user voice statement, clear acceptance criteria are added until the members of the agile team have a sufficient understanding of the requirement to be able to deliver the item.
Enabler Stories
Where there is work to be done by an agile team that does not directly benefit a user of the system, this can be expressed as enabler stories. Broadly, there are four main types of enabler stories:
Exploration – often referred to as a ‘spike’. The agile team perform an investigation to better understand available options and what work would be required to deliver a story planned for a later iteration.
Architecture – design a suitable architecture that describes the components in a system and how they relate to each other.
Infrastructure – perform some work on the solution infrastructure.
Compliance – complete an action required for compliance purposes, such as providing the documentation required by a regulatory authority.
There may be other activities that don’t fit into these four types, and they can still be written as enabler stories. The format for all enabler stories is straightforward:
Story statement – a simple, clear statement about what needs to be done.
Acceptance criteria - added until the members of the agile team have a sufficient understanding of the requirement to be able to deliver the item.
Features
Features are created by the product manager for an agile release train (ART). They flow through a programme kanban system. Part of that is the programme backlog, where the features are prioritised by the product manager. Features get broken down into stories by agile teams at programme increment (PI) planning events.
Features must be small enough to be delivered in a single PI by a single ART.
All features have the same basic format:
Phrase – a brief description of the feature.
Benefits hypothesis – a statement, which can be validated, about the benefits of the feature.
Acceptance criteria - added until the members of the agile teams, who will deliver this feature, have sufficient understanding of the requirement to be able to release the feature. Acceptance criteria also include any applicable non-functional requirements.
There are two categories of features, business features and enabler features.
Business Features
Business features directly benefit the business or its customers.
Enabler features
Where a feature does not directly benefit the customer or the business but completes the work necessary so that one or more business features can subsequently be implemented, this is an enabler feature.
Capabilities
Capabilities are items that exist at the large solution level in SAFe. This is an optional level.
Capabilities are created by the solution manager for a solution train. They flow through a solution kanban system. Part of that is the solution backlog, where the capabilities are prioritised by the solution manager.
Capabilities are items that are too big to be delivered in a single programme increment by a single ART and so are broken down into features. This is done by product and solution management, working in conjunction with solution and system architects/engineers. Generally, this will happen two weeks before PI planning, to allow time for the resulting features to be prioritised and socialised ahead of the PI planning events.
All capabilities have the same basic format as features:
Phrase – a brief description of the capability.
Benefits hypothesis – a statement, which can be validated, about the benefits of the capability.
Acceptance criteria - added until the product managers, who will take over content authority for the resulting features, have a sufficient understanding of the requirement to be able to write suitable features to be implemented by their respective ARTs. Acceptance criteria also include applicable non-functional requirements.
There are two categories of capabilities, business capabilities and enabler capabilities.
Business capabilities- Business capabilities directly benefit the business or its customers.
Enabler capabilities- Where a capability does not directly benefit the customer or the business but completes work necessary so that one or more business capabilities or features can subsequently be implemented, this is an enabler capability.
Epics
An epic describes a sizable initiative that is deliverable by an agile release train, solution train, or multiple solutions trains. Each epic has an epic owner, who could be anyone in the organisation, but is most likely a business owner or product professional.
As part of lean portfolio management, there will often be a ‘portfolio epic threshold’, above which the epic will be considered a portfolio epic, even if it could be delivered by a single ART or solution train. This might be based on the cost of the work or the risk to revenue streams by making the change.
Programme epic
A programme epic is deliverable by a single ART but would require more than one programme increment to do this. It has a business impact that is below the portfolio epic threshold.
Solution epic
A solution epic is deliverable by a single solution train but would require more than one programme increment to do this. It has a business impact that is below the portfolio epic threshold.
Portfolio epics
A portfolio epic is anything that has a business impact that is above the portfolio epic threshold or requires more than one solution train to be involved in the realisation of the initiative. Portfolio epics flow through a portfolio kanban system.
Format of epics
As with stories, features and capabilities, epics can be business epics or enabler epics. However, the format of an epic is more involved than that of features or capabilities, and typically has the following elements:
Name of epic
Epic owner
Description – a paragraph of text describing the epic that is clear and concise and covers who it is for, what it will do and what benefits it will bring.
Business outcomes – anticipated measurable benefits based on the above description
Leading indicators – early measures that will help validate the benefit hypothesis before the entire solution is implemented
Minimum viable product – the smallest possible selection of elements of the solution that can be used to validate the benefits hypothesis
When an epic is approved, it queues until it is converted into the capabilities and features necessary for the MVP. If the benefits hypothesis is validated by the MVP, then the rest of the aspects of the epic can be progressed.
Getting started
Remember that only stories and features are at the essential level, so starting with a single agile release train and getting used to these two ways to express requirements is a good way to start.