Requirements Structure
This guide describes how system requirements in Decision Focus are broken down into system epics, epics and features in Azure DevOps (ADO).
System epics, epics, and features include both requirement and planning content. This guide focuses on the requirement part – for more details on planning, prioritization, and follow-up, see the master process.
Intended for
Product owners, architects, scrum masters, test leads, and product managers.
Requirement classification
The requirements (system epics, epics and features) can be of three types:
- Business: Based on system requirements and has a value for the customer.
- Architectural: Feasibility studies, technical evaluations, architecture updates, etc.
- Enabler: Supports the implementation of business epics, including e.g. infrastructure, documentation, test, and gate preparations.
Level of requirements
System requirements
- A system requirement describes an addition, or delta, to an existing released system.
- A system requirement is based on a market opportunity derived from customer needs.
- A system requirement can be a requirement on system-, product- or component level, or a non-functional requirement (NFR) such as performance, standards, or legal.
- Change requests on system requirements are managed in Decision Focus.
System epics
- A system epic in ADO is cloned from a system requirement in Decision Focus, and additional information is added, e.g. involved streams and high-level estimates.
- Additional system epics of enabler type can be created by R&D, related to e.g. improvements, test environment preparations, and development of tests.
- A system epic is analyzed by R&D and broken down into epics.
Epics
- An epic is preferably solution-oriented with clear objectives.
- To implement a system epic, a set of epics is needed, typically including business, architecture, UX, Intellectual Property, and enabler types.
- An epic can only be assigned to one development stream (split if needed).
- Epics are analyzed by R&D and broken down into features.
Features
- A feature is typically related to a specific component.
- To implement an epic, a set of features is needed, typically including business, architecture, UX, Intellectual Property, and enabler types.
- A feature can only be assigned to one team (split if needed).
- Features are analyzed and broken down into user stories.
User stories
- A user story is treated as an activity (implementation, test, documentation or similar) and not treated as a "requirement".
Summary of requirement work items
| Type | Description | Size | Tool |
|---|---|---|---|
| System requirement | Describes a customer need (not a solution/implementation) in Decision Focus. Can result in changes in systems, products, or components. | Must fit in a release. | Decision Focus |
| System epic | Based on system requirement with some addtional information added. R&D can create additional system epics (enablers) if needed. | A system epic spans over several program increments (PIs) but must fit into a release. | ADO |
| Epic | Larger solution-oriented initiative developed by one stream. | Can span over several PIs but must fit in a release. | ADO |
| Feature | Smaller addition to a release, verified in component tests. | Can span over several iterations but must fit in a PI. | ADO |
| Story | Stories are short descriptions of a small piece of desired functionality written as tasks. | Must fit in one iteration. | ADO |
Requirement structure
System epics are broken down into epics and assigned to system and/or development streams for further refinement.
Workflow
- In the first step, system requirements are initiated from a market opportunity investigation. The system requirement is described, peer reviewed within PPM, and then sent to ADO (system epic created) for investigation.
- When the system epic is created, information from the system requirement is replicated to the system epic. An investigation is done to add details to the system epic. The investigation includes an implementation proposal where the need for architectural and intellectual property (IP) aspects is covered.
- The investigation of a system epic (in particular the estimated effort) gives input to complete the system requirement. At this point, the systsem requirement is preliminarily allocated to a release.
- As part of the PI grooming, the epics and features related to a system epic are refined until they meet definition of ready (DoR), see Definition of Ready and Definition of Done.
- Only epics and features that meet DoR are eligible for PI planning, where the scope for the increment is set.
- The epics and features are then implemented and verified.
- The system epic is closed when the implementation, verification, documentation, and other aspects of the definition of done (DoD) are completed, see Definition of Ready and Definition of Done for further information.
- The system epic will finally be available for the users when it part of a release.
Requirement grooming
The PI grooming (step 4 in the above workflow) is necessary to ensure that the PI planning.
Prerequisites to PI grooming
- Key stakeholders have allocated enough time for grooming (system/stream product owner 90%, stream architect 50%, team architect 25%, and stream test lead 25%).
- PPM has set the preliminary scope for the next PI.
- Known stream/team velocity (rough).
Grooming
The definition of epic and features shall follow the descriptions in How-to Work with Epics and How-to Work with Features.
The refinement of epics and features, also called grooming, involves detailing:
- Release scoping: Continuous grooming of system requirements and system epics to be allocated to a release proposal → Approved system requirements and system epics.
- Future release: Grooming of epics and features prior to release start → Epics and features with DoR.
- Ongoing release: Grooming of features remaining release scope → Features with DoR.
Grooming checkpoints
- Check 1: Preliminary scope for the next PI is set in the beginning of the ongoing PI (first sprint).
- Check 2: Progress and dependencies are checked halfway through the PI.
- Check 3: All features to be part of the next PI must meet DoR in the last sprint.
The stream owner is accountable for the checks, and can delegate to product owner or other suitable role.
Note: Don't groom too much or too little! The number of features brought into the PI should be matched to the increment capacity to avoid wasting excessive time for refining and planning features.
Maintaining requirements
After an epic has been closed, it is not maintained (nor its children). Two closed epics can even contradict each other.
The information from an epic/feature to be maintained is transferred to a product/component capability:
The capability should reflect the complete product for current and all previous releases over the product’s lifecycle. E.g., when an epic or feature is completed, the corresponding product or component capability is updated to reflect the additional change (delta). See Product Capabilities for further information.
Questions & answers
Q: What is an enabler?
To implement a business epic/feature/story, you may need to implement some basic technology or platform functionality, a.k.a. enabler. Identify such enablers when the business epic/feature/story is analyzed. R&D adds the enablers to the backlogs.
Other types of enablers, such as infrastructure, compliance, and improvements, need to be considered as well. They also require resources and should be identified and planned.
Q: What is a system requirement?
A system requirement is a requirement captured in discussions with customers by product management. System requirements can also be created for, e.g., standards, compliance, and NFRs. system requirements should explain the functionality expected to be developed, not the solution.
Q: Why is the size of a system requirement / system epic important?
The size is important! System requirements that come from PPM are of various sizes. The epics (and features) in the streams should be of similar size (to keep a continuous flow of completed epics - it is easier to show progress and become predictable). Even if the size of system requirements may vary, try to keep a similar size of business and architectural epics in the streams. It helps the product owners break down epics into features if they are of similar size (otherwise, merge or split them).
Agree with PPM on a suitable minimum size. If the system requirements are very small, R&D should not break them down further. A small system requirement results in even smaller epics/features/stories, and the administrative costs may increase.
Q: How do we refine estimates of epics and features?
Estimation of epics and features is done in steps. Initial estimation is done before breakdown. When the children have been defined, estimation is updated through aggregating the estimates of the children.
Q: Does PPM provide requirements for NFRs, compliance, and standards?
Yes - according to PPM, they manage these requirements as well.