How-to Work with System Architecture Epics and Features
The purpose of this guide is to provide hands-on support to the roles involved in defining the system architecture influenced by requirements, captured in the system epics, epics, and features.
As background to this guide, there is an existing conceptual REQ guide that focuses on the big picture.
The System architecture is strongly influenced by Technology and System Requirements. The overall architecture work is broken down into System Epics, Epics, and Features.
Architectural activities are one type of enabler from the perspective of SAFe methodology. However, to distinguish the architectural activities, this work is identified in ADO as the architectural value area.
Intended for
- Architects
- Product owners
- Developers
- Testers
In addition other roles with interest in the architectural work breakdown like Release owner, Product manager, and Supporting processes.
Overview
Work item hierarchy as below (every work item can have many children but only one parent). Each work item has Architecture as Value Area to differentiate it from the Technology and System Requirements work items.
- System Epic
- Epic
- Feature
- Epic
The architectural System Epic is sliced differently, covering multiple Technology and System Requirements.
Architectural System Epic
System and technology requirements are defined in Decision Focus (DF) for release planning. An Architectural System Epic covers one or several requirements, grouping the requirement into an architectural topic. In the process of defining the system architecture, the system architects create the system architecture epics based on the technology requirements.
The relationship between technology or system requirements and an Architectural System Epic is captured in the SR ID field for the Architectural System Epic.
A System Epic life cycle duration covers multiple increments. It's active for as long as there are children associated with it, after that point the system epic is closed. If new work within this topic is needed, the system epic is reopened.
The area path assigned to System Architecture and Value Area is set to Architectural.
System Epics vs. Requirements
Although requirements (System, Product, or Technology) are typically Product Managers' tools to provide functional and non-functional requirements to R&D, also R&D is entitled to file requirements.
This is typically done by Architects pushing for non-functional requirements related to architecture, design, and technology. Architects push for such requirements via the R&D toolchain by filing System Epics that will be translated into Epics.
The System Epics created by Architects (that will eventually translate into Epics/Features/User Stories/Tasks) may have higher or lower priority than a functional requirement created by PMs. This depends on a case by case, but it is important to notice that these epics value as much as the ones created by Product Management Team.
As happens for functional requirements, also the architectural requirements need to be discussed in regular epic grooming sessions and planned, according to the priority given by the originator, to the proper PI.
NOTE: if the requirement is created by Architecture team it may not necessarily have a related SR/TR in DFN to be linked
Architectural Epic
Architectural Epics are defined as a breakdown of the Architectural System Epics, one or several Architectural Epic are strictly associated with one Architectural System Epic as a parent/child relationship.
Each Architectural Epic always has one Definition of Ready and one Definition of Done, for more details refer to the Definition of Ready and Definition of Done Guideline. Templates are available in AppGami for Architectural Epic.
The Architectural Epic can focus either on investigation or documentation. Typically an architectural epic produces architectural documentation which would include some investigation. For some more details, an investigation is required, and this can be tracked with an investigation of an architectural epic. Depending on the focus, different DoDs are used.
An architectural epic can span 2 or more increments and is closed when the Definition of Done is fulfilled.
The area path assigned to System Architecture and Value Area is set to Architectural.
Architectural Epic Overview / Life Cycle
| Work Item State | Details |
|---|---|
| New | Work on the activity has not started. |
| Active | Architecture activities has started. Definition of Ready conditions have been met. |
| Resolved | The core activities are completed, but the work is not concluded. |
| Closed | All activities have concluded; Definition of Done conditions have been met. |
| Removed | The work item is no longer applicable, e.g. based on an assessment of need or a change in scope. |
Architectural Feature
Architectural Features are a further breakdown of the architectural epic into more details than expressed in the epic. Feature work items can be used to describe activities related to creating documentation for an architecture feature; for reviewing documents (e.g. for tracking PM-Architect agreement discussions), or for investigations or other objectives. In ADO, the Feature work item:
- Is typically scoped for completion within the increment
- Is assigned to a target sprint using the Iteration path field
- Is committed to a PCP System Planning Iteration
Each Architectural Feature always has one Definition of Ready and one Definition of Done, for more details refer to the Definition of Ready and Definition of Done Guideline. Templates are available in AppGami for Architectural Features.
Architecture documents are output from the Architectural Features and are published to the main branch of the wiki. Documents have four phases of readiness:
| Status | Description |
|---|---|
| draft | An architect has published document prior to peer review |
| in-review | Architecture team is conducting a peer review |
| pending | Document is ready for review by a broader audience (PCP R&D and PMs) |
| accepted | Reviews are completed by architecture and PMs: the accepted architecture is as documented |
The Architectural Feature is closed when the DoD conditions are met.
The area path assigned to System Architecture and Value Area is set to Architectural.
Architectural Feature Overview / Life Cycle
| Work Item State | Details | Documentation Feature Work Item |
|---|---|---|
| New | Work on the activity has not started. | The work item may be for creating a new document or revising an existing one. |
| Active | Architecture activities has started. Definition of Ready conditions have been met. | Any interim version of the architecture document would have draft status. The document may be published as a draft, or may be in a working branch as draft. If there is an original document it may already be published in some other state. |
| Resolved | The core activities are completed, but the work is not concluded. | The document is in review by the architecture team: a pull request is in review. |
| Closed | All activities have concluded; Definition of Done conditions have been met. | The document has been reviewed by the architecture team and the document has been published (merged to the main branch) with pending status |
| Removed | The work item is no longer applicable, e.g. based on an assessment of need or a change in scope. | -- |