How-to Work with System Requirements and System Epics
This guide describes how to handle system requirements and system epics. It includes descriptions and information about the system requirement / system epic definition, workflow, grooming, and change management.
For further information about the overview of requirements, see Requirements Structure.
Intended for
Product owners, product managers, architects, release owners, and test leads.
Activities
Initiate system requirement
The product manager creates a system requirement in Decision Focus. The system requirements are populated with title, description, motivation, compatibility, and product line. Target release shall be seen as preliminar, if filled in at this point in time. When requested information is in place, the system requirement shall be peer reviewed within the PPM organization. After a successful peer review, the system requirement is set to "Accepted" and replicated to Azure DevOps (ADO), and the corresponding system epic is created. Synchronization between Decision Focus and ADO is initiated.
Mandatory information that shall be included in the system requirement:
- Title: The title of the system requirement should briefly describe the functionality without pointing to a specific product, product line, or version.
- Description: A system requirement shall describe the wanted functionality and preferably not specify a specific technical solution. Try to write the description of the function so it can be understood without too much prior knowledge. Break down the functionality into several requirements if the function can be split up and still add value to the product (minimum viable functionality).
- Motivation: State the reason behind this requirement. If there is no associated market opportunity, the business motivation should be put here.
- Compatibility: Indicate to which category the system requirement belongs. Select between “Evolution”, “Enhancement”, and “New feature”.
- Product line: Indicate to which product line the system requirement belongs. Select between “Automated Vision”, “800xA”, “Symphony Plus”, and “Freelance”.
Investigate system epic
The created system epic shall be ranked in the ADO backlog to indicate in which order it should be investigated. In the investigation, analyze and detail the system epic by documenting a "solution intent". This includes describing the impacted life cycle packages, initial effort estimation, and confidence level. The solution intent shall include a high-level description of the technical solution and shall contain UX, architecture, and a draft epic breakdown. Complete the investigation by checking the system epic’s definition of ready (DoR).
The following information shall be included in the system epic:
-
Solution intent: Define the technical solution. Either in the description field or in an attached PowerPoint presentation.
-
Impacted dev. streams: Identify the impacted development stream(s), multiple select from: Control, Engineering, Operations, and IIoT.
-
Initial effort estimate: Provide an initial effort estimate based on the solution. Choose between predefined "buckets" of 200, 400, 800, 1600, 3000, and 5000 hours.
-
Confidence level: Indicate how confident the effort estimate is. Select between “Likely”, “Probably”, and “Certainly”, representing about 60, 75, and 95 percent, respectively.
Size Hours Comment (An epic can be implemented by one or several teams) XS 200 E.g. 2-3 persons for 7 weeks. S 400 E.g. 2 persons for 1/2 increment. M 800 E.g. 4 persons for 1/2 increment. L 1600 E.g. 4 persons for 1 increment. XL 5000 - Consider splitting (*) E.g. 13 persons for 1 increment or 6-7 persons for 2 increments. -
Area/iteration path and Target date shall be set when the underlying epics have been refined and the system epic has been allocated to a release.
-
In addition, some fields are not mandatory, e.g. priority, risk, business value, and start date.
-
See the Standard System Epic Template for more information.
R&D can add its own system epics of IP, architecture and enabler type. All fields are the same except that no information is replicated from Decision Focus.
Finally, review the fulfillment of the definition of ready (DoR) and involve relevant stakeholders.
- Functional: The related system requirement is approved, including "Description", "Motivation", "Product line", "Compatibility", Verification criteria", "Priority", "Target release".
- Functional: "Details" include a description of the solution intent.
- Enabler/Architectural/UX/IP: Understandable title, description, and acceptance criteria
- Area path set.
- "Initial Effort Estimation" with "Confidence level" set.
- Impacted development streams defined.
- The system epic shall be ranked in the backlog for the target release.
Set the system epic stage to "Investigated" when everything is ready.
Complete system requirement
When the system epic has been investigated, it is time to complete the system requirement. Define the verification criteria, IP relevance, priority, and preliminary target release based on the input described in the system epic. Consider also if any other fields need to be updated.
When all information is complete, the system requirement shall be reviewed by stakeholders defined in RACI. Set the system requirement to “Approved” in Decision Focus when the review is completed.
The following information shall be added to the system requirements:
- Verification criteria: Describe expectations for how the requirement shall be verified. What are the minimum aspects that must be checked?
- Intellectual property: Clarify if any Intellectual Property (IP) opportunity and/or risk is related to the system requirement.
- Target release: Preliminary definition of which release will include the system requirement.
Refine system epic
The system epic related to an approved system requirement is waiting in the backlog for further refinement, and the order is given by its place in the backlog. The refinement includes breakdown into epics and features. See the guides How to Work with Epics and How to Work with Features for information on how to define epics and features.
Refinement is required for a system epic to be eligible for inclusion in the program increment (PI) planning.
Epics and the features for the first PI shall meet DoR. Other features shall be well prepared.
Note: Refinement is done in parallel in several sub-streams.
The system product owner is responsible for driving the refinement, but can delegate (change “assigned to”) to the stream product owner with the most significant involvement. When the system epic is refined, it is ready for PI planning and implementation.
For more details about the requirement grooming, see the guide Requirements Structure.
Monitor implementation
Conduct regular sync meetings with key stakeholders (system product owner, product managers, architects, technical coordinators, and release owners) to monitor system epic progress, refine epics, and adjust their priorities and rankings.
Once the DoR for the system epic is met and the first child is set to "Active", the system product owner shall set the state of the system epic to "Active". The system product owner is responsible for ensuring the system epic is kept updated (state, iteration path, etc.) and for defining change requests towards system requirements as needed.
Identify and remove impediments (product owner, release owner, technical coordinator, product manager). Once all the children (epics) related to development are in the "Closed" state, the system product owner shall set the epic state to "Resolved". The epic is now ready for the system integration test (SIT).
If the system epic needs to be paused (e.g. due to changed product manager priorities, delayed delivery of dependent functionality, or unveiled technical uncertainties), the following shall be done:
- Set the system epic to "New" with the reason "Implementation halted".
- Update the iteration path to the new agreed-upon iteration, or without a defined iteration if it is not yet set.
- In the discussion field, elaborate on the reason to pause and describe how far the work has progressed.
- Ensure that linked child work items, not yet closed, have been managed in the same way.
- Ensure that dependent epics are informed.
Monitor test
System integration test cases to verify the epics shall be developed in parallel with the implementation of the epics. The system requirement verification criteria are input to the test cases. Typically, these tests are automated and include relevant hardware. Create an epic under the system epic to follow up on the system epic test activities.
For details about system epic testing, see the System Test Overview guide.
When all tests are completed, the bugs are resolved, and all documentation is in place, the system epic is ready to be closed.
Review and close
When all work has finished with a system epic, and all underlying epics are set to “Closed” (see epic description), the system product owner or the architect, depending on the system epic type, initiates closure.
Review the fulfillment of the definition of done (DoD) and involve relevant stakeholders.
- Confirm epics are completed.
- System integration tests (SIT) have been passed.
- Required documentation is reviewed and approved.
- The result is demonstrated and accepted by PPM.
Once the system epic DoD is met, change the state to “Closed.”
Details
Characteristics of system epics
System epics represent a significant initiative with the following characteristics:
-
Business value: System epics should drive substantial business value by addressing key strategic priorities and goals, resulting in significant improvements or innovations that support the business’s long-term objectives.
-
Size and scope: System epics are large in scale, often requiring significant time, effort, and resources. They typically span multiple increments and involve several streams.
-
Completeness: A system epic should be well-defined and comprehensive, with clear boundaries and deliverables, while minimizing dependencies. It should encompass all necessary work, from initial analysis through deployment and integration.
-
Clarity: System epics must be articulated clearly and include a thorough solution intent. This ensures that all stakeholders share a common understanding of the system epic's goals and expectations.
-
Alignment: System epics should align with strategic priorities and goals. Managing system epics effectively requires collaboration and communication; however, detailed execution is crucial. This ensures focus, optimizes resources, and delivers significant business value.
-
Result-oriented: The characteristics of a system epic include that it represents a set of lifecycle packages, products, or building blocks for various containers and components.
-
Testability: System epics should be designed to allow for thorough testing and verification. The integration strategy must consider how the lifecycle packages or products are integrated into the system and tested, see System Test Overview.
System epic example
Below is an example of a system epic with some of the key fields highlighted:
System epic change requests
Changes to systems epics that impact a system requirement shall be driven through a change request in Decision Focus and replicated to system epics and lower-level work items.
Changes to systems epics not impacting system requirements shall be handled without a change request as follows:
- Before DoR: Updates by system product owner or architect (inform product manager).
- Between DoR and DoD: Updates jointly by product owner, architect, and development team (inform product manager).
- After DoD: No changes are allowed; create a new system epic instead.
Note: Changes during an ongoing increment must be minimized. Excessive changes after the increment plans are committed decrease the team's performance. The teams need to focus on fulfilling their commitments in the increment.
System epic grooming
Refinement or grooming is an essential part of managing system epics. This activity ensures that epics are continuously updated, prioritized, and detailed as necessary. The focus of system epic grooming is to ensure a relevant release scope.
There is a significant effort in grooming when technology investigations and architecture updates are considered.
The grooming is capacity-based, i.e., the capacity for key roles involved in grooming (product managers, product owners, architects, etc.) is limited to accommodate grooming activities.
See Requirements Structure for details on how epics are refined during increments.
System epic state diagram
The state diagram illustrates the system's various states in relation to the activities. During the "new" state, the different preparation "stages" are shown with their relation to the activities.
Note: An epic can be canceled at any time. This is done by setting the children's feature state to "Removed", and then the epic’s state to "Removed". Cancel all implementation, test, and verification work and store intermediate results for future use.