# Epic

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/epic

## Quick definition

An Epic is a big chunk of work in Azure DevOps. It helps teams organize large projects into smaller pieces. Think of it as a big goal that gets split into smaller tasks called features and user stories. This makes complex projects easier to manage and track.

## Simple meaning

Imagine you are planning a huge family reunion. The overall event is too big to plan all at once. So, you break it down. The 'Epic' would be 'Plan the Family Reunion.' That is your big, top-level goal. Under that Epic, you might have 'Book the Venue,' 'Arrange Catering,' and 'Send Invitations', these are like Features. Then, each of those Features gets even smaller tasks, like 'Compare three venues,' 'Decide on a menu,' or 'Print address labels.' Those tiny tasks are User Stories. In Azure DevOps, an Epic works exactly this way. It is the highest level of work tracking for a major initiative that might take months or quarters. Epics are used to group related Features and User Stories, giving managers and stakeholders a clear view of progress on a large-scale objective. They are not assigned to a single person for a few days; instead, they are long-running organizational goals that many different teams will contribute to over time. By using Epics, everyone from developers to executives can see how small daily tasks connect to the company's big strategic goals, like launching a new product or migrating to the cloud. Without Epics, large projects can become a confusing mess of tiny tasks with no clear direction. With them, you have a clear map from the biggest goal down to the smallest action step.

## Technical definition

In Azure DevOps, an Epic is a work item type within the process template (Agile, Scrum, or CMMI) used to represent a large, strategic body of work that typically spans multiple sprints and often involves multiple teams. Epics reside at the highest level of the work item hierarchy, above Features and User Stories (or Product Backlog Items). In the standard Agile process, the hierarchy is Epic > Feature > User Story > Task. Each Epic can be linked to one or more Features, which in turn link to User Stories and Tasks. This hierarchical linking enables roll-up reporting and portfolio-level tracking.

Technically, Epics are stored in the Azure DevOps database as work items with a specific work item type ID. They contain standard fields such as Title, Description, State (e.g., New, Active, Resolved, Closed), Effort, Priority, and Area Path. Teams can customize the fields and workflow states to fit their needs. The Epic's Area Path can define which team or department owns the work, while the Iteration Path ties it to a specific timebox.

Epics are essential for Azure Boards and the built-in reporting tools. For example, the 'Epics' query can filter all work items of that type, and the 'Sprint' and 'Portfolio' backlogs allow teams to view and manage Epics alongside lower-level items. Custom dashboards can be built using widgets like the 'Work Links' or 'Chart for Work Items' to show Epic progress, such as percentage of linked Features closed.

In real IT implementations, Epics are particularly useful for large-scale initiatives like 'Migrate legacy CRM to Salesforce' or 'Deploy new microservices architecture.' Each Epic contains multiple Features (e.g., 'Database migration,' 'API creation,' 'User interface redesign'), each with many User Stories. The Epic lifecycle often includes a formal review at the 'Active' state to validate alignment with business goals before Features are broken down. Azure DevOps allows Epics to be tagged, related to other work items, and commented on, providing full traceability. The 'Epic' concept is also used in SAFe (Scaled Agile Framework) where Epics are even larger and may cross many teams and months of work. Understanding how to properly size and decompose Epics is a key skill for product owners and project managers certified under PMI-ACP or involved in Microsoft Azure DevOps certifications.

## Real-life example

Think about building a new house. The 'Epic' is 'Build a New Home.' That is the huge, overarching goal. You cannot just go out one Saturday and build a house. So, you break it into features: 'Design the Floor Plan,' 'Pour the Foundation,' 'Frame the Structure,' 'Install Plumbing,' 'Run Electrical Wiring,' 'Finish Interior Walls.' Each feature is still large. So, you break those down further into user stories. For example, under 'Install Plumbing,' you might have 'Install kitchen sink,' 'Install bathroom toilet,' 'Install outdoor faucet.' Those are things you can actually complete in a few days. The Epic 'Build a New Home' ties everything together. The architect and the general contractor use the Epic to see the big picture. They can check if the foundation is done (feature closed) and how many plumbing tasks remain. If the homeowner wants a change, like adding a guest bathroom, that change becomes a new Feature under the same Epic, and new User Stories are created. The Epic remains open until the final inspection and move-in. In IT, this same logic applies. A company might have an Epic called 'Migrate All Servers to Azure Cloud.' Under it, features like 'Assess Current Environment,' 'Migrate Database Servers,' 'Migrate Web Servers,' 'Train IT Staff.' Each feature has many user stories like 'Install Azure Backup Agent on SQL Server.' The project manager views the Epic to report to executives on overall migration progress, without getting lost in tiny tasks.

## Why it matters

The concept of an Epic matters in practical IT because it bridges the gap between high-level strategic goals and the detailed day-to-day work of development teams. Without Epics, large initiatives like 'Implement Zero Trust Security' or 'Build a Mobile Banking App' become amorphous and unmanageable. Managers and stakeholders have no clear way to see how smaller tasks contribute to the big picture, leading to misalignment and wasted effort. Epics provide a structured way to decompose huge goals into measurable, assignable chunks. They enable portfolio-level reporting, executives can view an Epic's progress at a glance, seeing that 5 out of 10 Features are complete, which gives a realistic sense of project completion. In Azure DevOps, this roll-up is automatic when features and user stories are properly linked. Epics also help with budgeting and resource allocation. A team working on an Epic can be given a specific portion of the budget, and progress can be tracked by the effort (story points or hours) consumed. If an Epic shows signs of delay, leadership can intervene early. Epics facilitate communication across teams. When multiple teams contribute to the same Epic, each team can own specific features and user stories, yet the Epic represents a shared goal. This reduces duplication of work and ensures everyone is building the same overall solution. In real-world scenarios, projects that fail often do so because the big picture was not captured or tracked. Epics directly address that failure point.

## Why it matters in exams

Understanding Epics is critical for several IT certification exams, particularly those focused on Azure DevOps, agile project management, and the Scaled Agile Framework (SAFe). For the Microsoft Azure DevOps Solutions exam (AZ-400), the hierarchy of work items is a core topic in the 'Plan and Design an Agile Work Management Process' domain. Questions may ask you to identify which work item type should be used for a specific scenario: e.g., 'A new strategic initiative that will take three quarters to complete requires tracking. Which work item type should you create?' The correct answer is Epic. Similarly, the Microsoft Azure Fundamentals (AZ-900) may have light supporting questions about Azure Boards capabilities, including work item types. For the PMI Agile Certified Practitioner (PMI-ACP) exam, Epics are covered in the context of product backlog management and release planning. Candidates need to know when to create an Epic versus a Feature versus a User Story, and how to decompose Epics appropriately. The SAFe Agilist certification (SAFe 5 or 6) heavily focuses on Epics as one of the three levels of work (Epic > Feature > Story), and expects you to understand the 'Epic Hypothesis Statement' and the 'Lean Business Case' used to approve Epics. In exam questions, you may encounter scenarios where a product owner is unsure whether to create a Feature or an Epic. The trap often involves choosing Feature when the work spans multiple teams and releases, that should be an Epic. Another common question type: 'Which tool in Azure DevOps provides a portfolio-level view of Epics?' The answer is the Portfolio Backlog. These exams expect you to apply the concept, not just memorize definitions, so practicing with sample work item hierarchies is beneficial.

## How it appears in exam questions

Exam questions about Epics appear mainly in scenario-based formats. A common pattern describes a large project, e.g., 'Your company is planning to modernize its data center by migrating to Azure over six months. This initiative involves four teams and will be tracked in Azure DevOps. You need to create a work item hierarchy. Which work item type should represent the overall migration?' The correct answer is Epic. Distractors might include Feature (too small) or Task (too granular). Another pattern: 'You have an Epic named 'Redesign Corporate Website'. The Epic contains 10 Features. One of the Features, 'New Navigation Menu', contains 12 User Stories. A stakeholder asks for a high-level progress summary. Which Azure Boards view should you share?' The answer is the Epic's work item page or a custom dashboard showing Epic progress with linked Features. There are also configuration questions: 'Which field in Azure DevOps can you use to associate an Epic with a specific department?' Answer: Area Path. Troubleshooting questions might involve linking issues: 'You created an Epic, but its linked Features are not showing up on reports. What could be the cause?' Possible answers: 'The Features are not directly linked to the Epic' or 'The query filter does not include Features.' Finally, exam questions may test the difference between Scrum and Agile process templates regarding Epics. For instance, 'In the Scrum process template, what is the equivalent of an Epic?' The answer is that Scrum also uses Epic as a work item type, but the hierarchy differs slightly (Epic > Feature > PBI > Task). Understanding these subtleties is key.

## Example scenario

You are a junior project manager at a tech company. The CEO announces a strategic goal: 'We must achieve PCI DSS compliance for our e-commerce platform by the end of the year.' This is a massive effort involving the security team, development team, and operations team. You decide to create an Epic in Azure DevOps called 'PCI DSS Compliance Initiative.' Under this Epic, you create Features like 'Assess Current Security Gaps,' 'Encrypt Credit Card Data at Rest,' 'Implement Access Controls,' 'Update Firewall Rules,' and 'Conduct Penetration Testing.' Each Feature has User Stories. For 'Assess Current Security Gaps,' you create stories: 'Review existing network diagrams,' 'Identify all systems that store cardholder data,' 'Document current encryption methods.' Each User Story is assigned to a team member and estimated in story points. The Epic itself is not assigned to anyone but is owned by you as the project manager. You schedule a weekly sprint review meeting where you show the Epic progress: 2 of 5 Features are complete (40%). The security team reports that 'Encrypt Credit Card Data at Rest' is in progress, and two stories under it are done. When the CEO asks for an update, you simply show the Epic board, which visually indicates the percentage of completed Features and User Stories. If a new regulatory requirement emerges mid-year, such as 'Implement logging for all admin access,' you add a new Feature under the existing Epic. By the end of the year, all Features are closed, the Epic is marked as Done, and the company achieves compliance. Without the Epic, tracking this complex project across multiple teams would have been chaotic.

## Common mistakes

- **Mistake:** Creating an Epic for a task that can be completed in one sprint.
  - Why it is wrong: Epics are meant for large strategic initiatives spanning multiple sprints or quarters. A one-sprint task should be a Feature or User Story.
  - Fix: Ask yourself: Will this work require more than one team or more than one month? If not, use a Feature or Story instead.
- **Mistake:** Assigning an Epic directly to a developer for completion.
  - Why it is wrong: Epics are too large for one person to own. They represent cross-team work. Assigning an Epic to an individual causes confusion and lacks accountability.
  - Fix: Assign the Epic to a product owner or project manager responsible for the initiative, not to a single developer.
- **Mistake:** Creating an Epic without breaking it down into Features and User Stories.
  - Why it is wrong: An Epic with no linked children cannot be tracked in detail. It becomes a vague goal with no actionable plan, defeating the purpose of agile tracking.
  - Fix: Always decompose an Epic into at least 2-3 Features immediately after creation, and plan to further decompose into User Stories.
- **Mistake:** Using Epics to track every minor improvement or bug fix.
  - Why it is wrong: Overusing Epics clutters the portfolio backlog and dilutes the meaning of strategic initiatives. Minor improvements should be Features or User Stories.
  - Fix: Reserve Epics only for major business objectives that require coordinated effort across multiple teams and have a significant impact.
- **Mistake:** Not updating the Epic's state as progress occurs.
  - Why it is wrong: If the Epic remains 'New' for months, stakeholders cannot see progress. This undermines the purpose of using Epics for reporting.
  - Fix: Update the Epic state to 'Active' when work starts, and close it only when all child Features and Stories are completed and the objective is fully met.

## Exam trap

{"trap":"Classifying a large, well-defined requirement that can be implemented by a single team in 2-3 sprints as an Epic.","why_learners_choose_it":"Learners think that because the requirement is big and takes multiple sprints, it must be an Epic. They miss the nuance that Epics are reserved for initiatives that cross team boundaries or have high strategic business value.","how_to_avoid_it":"Ask these two questions: Does this work involve only one team? Is it purely tactical (e.g., adding a feature to existing software)? If yes, it is likely a Feature, not an Epic. Reserve Epics for strategic goals that require coordination across multiple teams or departments."}

## Commonly confused with

- **Epic vs Feature:** A Feature is smaller than an Epic and represents a specific functionality that delivers value to a user or stakeholder. While an Epic is a high-level initiative, a Feature is a concrete piece of work that can be completed in a few sprints by one team. Epics contain multiple Features. (Example: Epic: 'Mobile App Overhaul' contains Features: 'Redesign Login Screen', 'Add Biometric Authentication', 'Implement Push Notifications'.)
- **Epic vs User Story:** A User Story is the smallest unit of work in an agile backlog, representing a single requirement from a user's perspective. It is typically completed within one sprint by one person. Epics are far larger and contain many Features, each of which contains many User Stories. (Example: For the Feature 'Add Biometric Authentication', a User Story could be: 'As a user, I want to scan my fingerprint to unlock the app.' The Epic would be the whole overhaul.)
- **Epic vs Theme:** A Theme is a collection of Epics or Features that share a common business objective, often used for strategic grouping across a program. Themes are even broader than Epics and are not a work item type in Azure DevOps. They are more of a conceptual grouping used in roadmapping. (Example: Theme: 'Improve Customer Experience' could include Epics: 'Mobile App Overhaul', 'Website Redesign', 'Chatbot Implementation'.)
- **Epic vs Task:** A Task is the most granular work item, representing an individual action needed to complete a User Story. Tasks are typically estimated in hours. Epics are the opposite end of the hierarchy, strategic and large, while Tasks are tactical and tiny. (Example: For a User Story 'Add fingerprint scan', a Task could be 'Integrate Android Biometric SDK'. The Epic would be 'Mobile App Overhaul'.)

## Step-by-step breakdown

1. **Identify a Strategic Initiative** — A product owner or manager recognizes a large business goal that cannot be achieved in a single sprint. Examples include 'Enter European market with localized product' or 'Migrate on-premise infrastructure to cloud.' This step validates the need for an Epic.
2. **Create the Epic Work Item in Azure DevOps** — Navigate to Azure Boards, select the correct team project, and create a new work item of type 'Epic.' Fill in essential fields: Title, Description that includes the business case, and set initial State to 'New.' Optionally, assign an Area Path to indicate ownership.
3. **Decompose the Epic into Features** — Break the Epic into 3-10 concrete Features that together deliver the Epic's goal. For example, for an Epic 'Cloud Migration,' create Features like 'Assess Current Environment,' 'Migrate Databases,' and 'Train Staff.' Link each Feature as a child of the Epic using the 'Parent/Child' relationship.
4. **Decompose Features into User Stories** — For each Feature, create User Stories that define specific, actionable requirements. For the Feature 'Migrate Databases,' create stories such as 'Copy production SQL database to Azure SQL Managed Instance.' Link each User Story as a child of the Feature.
5. **Set Iteration Paths and Team Assignments** — Assign the Epic to a high-level iteration (e.g., a quarter). Then, assign Features and User Stories to specific sprint iterations. This ties the Epic to a timeline and ensures teams know which sprint items belong to the Epic.
6. **Track Progress and Update States** — During daily stand-ups and sprint reviews, update the state of User Stories (to Active, Resolved, Closed), then Features, and finally the Epic. Use the Epic page's 'Children' tab to see roll-up progress. Change Epic state to 'Active' when work starts, and to 'Closed' only when all Features are complete.
7. **Review and Adjust the Epic as Needed** — Periodically, stakeholders review the Epic's progress against business goals. If the scope changes, add or remove Features. If the Epic is no longer viable, mark it as 'Removed.' Regular review ensures the Epic remains aligned with strategy.

## Practical mini-lesson

In practice, using Epics effectively requires discipline in both creation and maintenance. As a professional, you must ensure that every Epic has a clear and concise business justification. This is often referred to as the 'Epic Hypothesis Statement' in SAFe, which includes the Epic's expected benefits, cost, and measurable success criteria. In Azure DevOps, you can capture this in the Description field or using custom fields. A common mistake is to treat the Epic as just another label for a big to-do list, but it should be treated as a contract between the development teams and the business stakeholders.

When configuring Azure DevOps, you can customize the Epic work item type by adding fields like 'Business Value' or 'Stakeholder Approval Date.' This can be done through the Process templates. For example, in the Agile process, you can add a field called 'Epic Business Value' with a dropdown of High, Medium, Low, which helps prioritize Epics in the portfolio backlog. The portfolio backlog view in Azure DevOps is specifically designed to show Epics at the top level, allowing you to expand them to see Features and Stories. This view is crucial for quarterly planning sessions (e.g., PI Planning in SAFe). If your organization uses multiple teams, each Epic's Area Path should be set to the highest-level area that encompasses all contributing teams, enabling roll-up reports.

What can go wrong? If Epics are too large (five years long) or too vague, they become meaningless. If they are too small, they blur with Features. The heuristic: if you cannot explain the Epic's value in two sentences to a non-technical executive, it is too vague. Also, if the Epic does not have at least two Features after a week of refinement, you are not thinking broadly enough. Another practical pitfall is not linking child work items correctly. In Azure DevOps, if a Feature is not explicitly linked as a child of the Epic, roll-up reports will miss it. Always use the parent-child link type via the 'Create links' dialog. Finally, remember that Epics are not just for developers. They involve marketing, sales, legal, and operations. So, when you add comments or attachments to an Epic, include cross-functional stakeholders to keep everyone informed. This makes the Epic a true collaboration hub for major initiatives.

## Memory tip

Epic = Extra-large Project, Involving Cross-team Cooperation. Think E-P-I-C: Each Epic Project Involves Cross-team Cooperation.

## FAQ

**Can a single team own an Epic?**

Yes, a single team can own an Epic if the initiative is limited to that team's scope. However, if the Epic requires multiple teams' contributions, it should be owned by a product manager or program manager who oversees the cross-team effort.

**How do I know if something should be an Epic or a Feature?**

An Epic should represent a strategic business objective that is too large for one sprint or one team. A Feature is a specific functionality that delivers value to users. If it takes a quarter or longer and involves multiple teams, it is likely an Epic.

**Do I need to assign story points to an Epic?**

It is not necessary to assign story points directly to the Epic. Instead, the Epic's progress is measured by the story points of its child User Stories. Azure Boards can roll up the total story points from all children automatically.

**Can I link an Epic to other Epics?**

Yes, you can link Epics using 'Related' or 'Parent/Child' link types. However, it is generally better to keep the hierarchy flat (one parent Epic) to avoid complexity. Use 'Related' for Epics that are part of a larger Theme.

**What is the difference between an Epic in Azure DevOps and a SAFe Epic?**

Both represent large initiatives, but SAFe Epics are even larger and typically require a formal 'Lean Business Case' and approval at the portfolio level. Azure DevOps Epics can be used for any size initiative and are more flexible.

**Can I delete an Epic in Azure DevOps?**

You can permanently delete an Epic or change its state to 'Removed' to keep it for historical reference. Deleting removes all linked child work items, so it is safer to change the state.

**How do I report on Epic progress in Azure DevOps?**

Use the 'Portfolio Backlog' view which shows Epics with expandable child Features and Stories. You can also create a dashboard with a 'Chart for Work Items' widget showing the count of Epics by state or the roll-up of story points.

## Summary

An Epic in Azure DevOps is the highest-level work item used to capture large strategic initiatives that span multiple teams and sprints. It provides a container for Features and User Stories, enabling teams to break down huge goals into manageable pieces while maintaining a clear view of overall progress. In IT certification exams, particularly for Azure DevOps, PMI-ACP, and SAFe, understanding when to create an Epic versus a Feature or User Story is critical. Exam questions often present scenarios where you must choose the correct work item type based on scope, team involvement, and business impact. Common mistakes include treating every large task as an Epic, failing to link child work items, or not updating the Epic's state. By mastering the Epic concept, you will be better prepared for portfolio-level planning, stakeholder reporting, and ensuring that development work aligns with strategic business objectives. The takeaway for exam success is to remember that Epics are for strategic, cross-team, long-duration initiatives, and they must always be decomposed into smaller, trackable items. This structured approach is what distinguishes successful agile project management from chaotic, disconnected work.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/epic