How-to Work with Epics

This guide describes how to handle epics in streams. It includes examples of epic descriptions and information about the epic definition, grooming, and change management.

For further information about epics and other requirements, see Requirements Structure.

Intended for

Product owners, architects, release owners, and product managers.

Activities

Create

From the implementation proposal driven by the system product owner on system epics, create epics and assign them to development streams. Each epic should only be assigned to one development stream – epics cannot be shared between streams.

Add initial information to the epic work item, including:

• "Title": A concise name that provides understanding and context.
• "Owner": Must be set to the responsible product owner for the epic.
• "Area": Must be set to the release/product where the epic will be delivered.

Refine and estimate

Analyze and refine the epic and its implications for the stream architecture.

The following fields are mandatory in the epic work item:

• The “Value area” under “Classification” defines the type of epic and can be set to:

  • "Business": Based on system requirements, has a value for the customer.
  • "Architectural": Feasibility studies, technical evaluations, architecture updates, etc.
  • "UX": For UX related efforts.
  • "Intellectual Property": for IP related efforts.
  • "Enabler": Supports the implementation of business epics and administrative tasks.
  
  

• The "Description" must contain a "story" and indicate if/how the epic will be demonstrated. To clarify the scope and avoid unnecessary enhancements, limitations should be clearly defined using "not included" (limitations may pertain to functionality, operating systems, services, etc.). Initial ideas on implementation should be documented under "Details" with text or links to other material, such as an implementation proposal. Epics are defined as vertical slices of the product with end-user value as the main perspective. When defining an epic, one should think about how the completion of the epic improves the end-user experience.

  The analysis may reveal the need for further investigations, platform development, test environments, and other administrative work. Identify and create enabler work items for this work related to the system requirements, but not explicitly defined.

• The "Acceptance Criteria" defines the requirements that must be met and verified for epic acceptance. Typically, 3-5 criteria are adequate. The acceptance criteria are preferably documented in Gherkin syntax: Given <initial context> When <event> Then <expected outcome>. This ensures clear definitions and facilitates test case automation.

  Note: There is a difference between acceptance criteria and definition of ready (DoR), and it is not OK to define the acceptance criteria as "Consider DoR".

  • Acceptance criteria: Criteria for content, different for each work item.
  • DoR: Criteria for processes, the same for every work item type.

• "Security Relevant" defines whether the epics have an impact on security and should be set to either “True” or “False”. This includes to check if the work affects a security-critical component or alters its attack surface. Consider changes in authentication, access control, integrity checking, encryption, or denial-of-service (DoS) protection measures. Refer to Security Criticality Analysis for details. Evaluating the security relevance of an epic is essential for system security and data protection.

• Identify any dependencies. Under "Related Work" link system epic (as parent) and features (as children), including architecture, development, enabler(s), user experience, and test features. Link any work item, using (predecessor) or (successor) if dependencies affect implementation order.

  Note: Every epic should be linked to one system epic.

• An epic must fit the release and can span several increments. It is recommended to refine (split) epics into the size of 1-2 increments. In "Effort" provide an initial high-level estimate of the epic in hours using t-shirt estimation, see example below. This is a first rough estimate, updated once the features are defined and estimated. Include the product manager, product owners, test lead and stream architects in the estimation process.

  Size	Hours	Comment (An epic can be implemented by one or several teams)
  XS	500	E.g. 2-3 persons for 7 weeks.
  S	1000	E.g. 2-3 persons for 13 weeks or 4-6 persons for 7 weeks.
  M	2500	E.g. 4 persons for 20 weeks or 6-8 persons for 7 weeks.
  L	5000	E.g. 6 persons for 26 weeks or 8-9 persons for 18 weeks.
  XL	7500 - Consider splitting (*)	E.g. 6-7 persons for 39 weeks or 9-10 persons for 26 weeks.

• "Iteration path" shall describe in which increment the epic will be ready. When an epic is under preparation, this field can be left empty, but it shall be filled out no later than it is set to “Active”.

• "Target date" is a more specific indication of when the epic is ready. This allows the product and system test teams to better plan. Avoid setting all epics to the end date of the increment.

• The "Planned Demo" field must be "Yes" or "No" to indicate whether the epic result is scheduled for demonstration within the stream.

• In addition, some fields are not mandatory, e.g. priority, risk, business value, time criticality, and start/target date.

Approve and rank

Ensure that the epic contains all the necessary information for implementation and verification, and that key stakeholders agree to the estimate. The epic must meet the criteria outlined in the DoR of the epic work item.

• Understandable "Title" and "Description".
• Testable acceptance criteria established.
• If/how to demo defined.
• Effort estimated.
• Link to system epic.
• Dependencies to other epics defined.
• Preliminary stream architecture defined (e.g. in PPT).
• Draft features (including e.g. business, architecture, UX and documentation).
• The area and iteration path are set.
• Target date specified.
• Security impact considered.
• The epic is ranked in the backlog.
• Epic reviewed.

The last DoR bullet asks for a review of the epic. The product owner or the architect reviews the epic’s DoR with participants according to RACI for epics as stated in the Requirements artifacts table.

Note the RACI roles for the review meeting:

• (R) drives the meeting.
• (C) needs to either attend the meeting or provide written comments (“No comments” is also an alternative).
• (A) and (I) are invited as optional and do not have to attend or provide comments.

If someone is important for the review but not covered by the RACI, they should be invited as well.

If the epic is approved, check the box “Epic reviewed” and add a note in the discussion field with the conclusion of the review (including any important notes) and the names of the participants. One review meeting can cover many epics.

If an epic is not subject to review of DoR, the reason shall be noted in the discussion.

Rank the epic by comparing it to other approved epics in the stream backlog. Drag-and-drop epics in Azure DevOps (ADO) to do the ranking.

Monitor implementation

Conduct regular stream sync meetings with key stakeholders (product owner, stream architects, technical coordinators, and release owners) to monitor epic progress, refine epics, and adjust their priorities and rankings.

Once the DoR for the epic is met and the first child is set to “Active”, the product owner shall set the state of the epic to “Active”. The product owner is responsible for checking that the epic is kept updated (state, iteration path, etc) and that change requests towards system requirements are defined when needed.

Identify and remove impediments (product owner, release owner, technical coordinator, product manager). Once all the children (features) are in the “Closed” state, the product owner shall set the epic state to “Resolved”. The epic is now ready for the product integration test (PIT).

If the epic needs to be paused (e.g. due to changed product manager priorities, delayed delivery of dependent functionality, or unveiled technical uncertainties) the epic shall be:

• Set the epic to “New” with the reason “Implementation halted”.
• Update iteration path to agreed new iteration or without 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 proceeded.
• Ensure that linked child work items, not yet closed, have been managed in the same way.
• Ensure that dependent epics are informed.

Monitor test

Product integration test cases to verify the epics shall be developed in parallel with the implementation of features. The epic acceptance criteria are input to the test cases. Typically, these tests are automated and include relevant hardware. Create a feature under the epic to follow up on the epic test activities.

For details about epic testing, see the Product Test Overview guide.

When all tests are completed, the bugs are resolved, and all documentation is in place, the epic is ready to be closed.

Review and close

When all work has finished with an epic, and all underlying features are set to “Closed” (see feature description). The product owner or the architect, depending on the epic type, initiates closure.

Review the fulfillment of the definition of done (DoD) and involve relevant stakeholders.

• All child features are closed.
• All product integration tests (PIT) passed, and existing bugs have CCB decision.
• Product-level documentation approved (e.g. architecture and product capabilities).
• Epic demonstrated.
• Input to end-user documentation and release notes provided.
• Installation/delivery package updated.

Once the epic's DoD is met, change the state to “Closed.”

Details

Characteristics of epics

Epics represent a significant initiative with the following characteristics:

• Business value: 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: Epics are large in scale, often requiring significant time, effort, and resources. They typically span multiple increments and involve several teams.

• Completeness: An 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: Epics must be articulated clearly, with well-defined objectives, requirements, and acceptance criteria. This ensures that all stakeholders share a common understanding of the epic’s goals and expectations.

• Alignment: Epics should align with strategic priorities and goals. Managing 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 an epic include that it represents a lifecycle package, product, or building block for various containers and components

• Testability: Epics should be designed to allow for thorough testing and verification. The acceptance criteria must consider how the components and containers are integrated into lifecycle packages or products and tested, see Product Test Overview.

Epic example

Below is an example of an epic with some of the key fileds highlighted:

Epic change requests

Changes to 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 epics not impacting system requirements shall be handled without a change request as follows:

• Before DoR: Updates by product owner or architect (inform development team and 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 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.

Epics grooming

Refinement or grooming is an essential part of managing epics. This activity ensures that features are continuously updated, prioritized, and detailed as necessary. The main focus of grooming is on the upcoming increment.

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.

Epic state diagram

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.

References

• Product Capabilities
• Product Test Overview
• Requirements Structure
• Security Criticality Analysis