ServiceNow Epic Explained

Defining Epic in ServiceNow Work Management

An epic in ServiceNow work management is a large body of work with a single strategic objective that typically spans several weeks or months to complete. An epic is not a single task or deliverable; it is a container for multiple related stories and tasks that together accomplish a business goal. An example epic might be “Implement multi-factor authentication across the organization.” This is a large initiative requiring security assessment, technology selection, infrastructure configuration, user training, phased rollout, and monitoring. A single person cannot do all this work in a few days. An epic captures the entire initiative and the collection of stories and tasks needed to complete it.

Epics sit at a higher level of abstraction than stories. A story describes a specific user-facing capability (“as a user, I want to authenticate using a hardware token so I can securely access systems”). An epic describes the overall business initiative (“implement multi-factor authentication”). The epic contains many related stories, each describing a specific piece of the larger whole. Epics help organizations manage complex, multi-team initiatives and communicate the overall direction and scope.

Where Epics Live in the Platform and How They Connect

Epics live in the work management module (or could be called Initiatives or Programs depending on your terminology). Each epic has a title, description, business justification, strategic alignment, target completion date, and estimated effort. An epic links to multiple child stories and tasks that execute the epic. Epics also link to related configuration items, change requests, or projects if they are implementing infrastructure or organizational changes. The epic is the hub connecting all the detailed work to the larger business goal.

Epics typically roll up to a product roadmap or strategic plan. A product team might publish their roadmap as a set of epics for the quarter or year: “improve performance,” “add integrations,” “enhance security,” “expand analytics,” and so on. Each epic contains the stories and work that contributes to that strategic priority. This structure communicates direction to stakeholders and coordinates work across the organization. Team members see the epic and understand why their story and task matter; they are not just executing an isolated piece of work but contributing to a strategic initiative.

Worked Example: Multi-Factor Authentication Epic

Imagine implementing multi-factor authentication across the organization. This is an epic because it requires months of coordinated effort across multiple teams. The epic “Implement multi-factor authentication” might contain these stories: “security team completes risk assessment and selects a vendor,” “IT team sets up MFA infrastructure in the primary systems,” “identity team configures MFA for user population,” “helpdesk trains on MFA support and troubleshooting,” “communications team announces MFA to all users,” “HR and management enforce MFA authentication requirement,” “security monitors for compliance and troubleshoots edge cases.” Each story is a discrete piece of work owned by a specific team, with clear acceptance criteria and definition of done. The epic provides narrative and coordination: teams know the order in which work should happen, understand dependencies (security assessment must complete before vendor selection, vendor selection must complete before infrastructure setup), and can report progress toward the overall initiative.

An epic also provides metrics and reporting: when all stories are complete, the epic is complete. Burn-down charts show how much work remains. Dashboards show which epics are on track, which are at risk, and which are blocked. Executives reviewing strategic initiatives see this epic and understand: multi-factor authentication implementation is one quarter in progress, on track to complete in Q2, with the number of people involved and the days of effort remaining. This visibility into strategic work is only possible because the epic coordinates multiple related stories and tasks.

Common Misconceptions About Epics

A frequent misconception is that an epic is similar to a project. They are related but distinct. A project is usually managed by a project manager with defined start and end dates, a budget, a team, and a status report. An epic is a work management container that organizes stories into a strategic initiative. The same epic might span multiple projects, or one project might contain multiple epics. Projects are about execution and management; epics are about strategy and scope.

Another misconception is that epics require complex hierarchy levels (epics → initiatives → stories → tasks). Some organizations use this hierarchy; others use two levels (epics directly containing stories). The hierarchy depth depends on the complexity and scale of work. A small feature might have just stories, no epic. A large transformation might use both epics and initiatives. Avoid over-structuring; use enough hierarchy to communicate clearly, not more.

A third misconception is that epics must span months. An epic could span weeks if the work is large and complex enough to need that structure. Similarly, a story should probably not be called an epic; if the work is discrete enough to complete in a sprint, it is probably a story, not an epic. The distinction is about scope and complexity, not calendar time. Use epics to organize large, complex work that requires coordination across teams or over extended time.

Related Concepts and Interactions

Epics relate to several other work management concepts. Roadmaps organize epics by time period and strategic priority, showing the planned work for the quarter or year. Themes are often another level of organization above epics: a theme might be “improve performance,” and under it are multiple epics focused on different aspects of performance improvement. Features are sometimes used interchangeably with epics, depending on terminology. Some organizations call them epics; others call them features or initiatives. The naming matters less than clarity: team members understand how work is organized and what each level means.

Epics should be tracked in the same work management system as stories and tasks so that status and effort roll up correctly. If epics are managed in a separate tool from story-level work, visibility breaks: executives see epic status but cannot see whether underlying stories are progressing. If stories are tracked but not organized into epics, teams lose the ability to communicate and coordinate large initiatives. Integration is essential for effective work management.

What an epic is for when the work is ambiguous

Teams reach for an epic when a piece of work is too large to hold in one story and too uncertain to plan in full. The epic is the container that lets a group agree on the outcome before anyone agrees on the steps. A common failure is creating an epic that is really a wish list, with forty stories and no shared definition of done. That structure looks organized in a backlog view and tells nobody when the outcome has arrived. The useful epic is written around one outcome that a sponsor could check, with a short list of the decisions still open. If the outcome cannot be checked, the epic is not ready to be planned.

The people who should write the epic are the sponsor and the lead who will deliver it, not only the team that will execute it. The sponsor owns the outcome and the lead owns the path, and the epic records both.

Deciding whether a body of work should be an epic

Not every large item needs an epic. The table sets out the options that sit around an epic, because the choice is often between a container and a plain backlog of linked stories.

Option	Use it when	Warning sign	What it does not give you
Single story with subtasks	Work is one deliverable that fits one sprint or release	Subtasks start to carry their own acceptance criteria	Visibility of a multi-team outcome
Epic with linked stories	Work spans several teams and an outcome has to be tracked	Stories are added with no reference to the outcome	Automatic rollup of effort unless fields are kept consistent
Project with a plan	Dates, budget and a fixed scope are part of the commitment	The epic is used as a substitute for a plan nobody maintains	Flexibility to re-scope as the outcome becomes clearer
Strategic theme above epics	Several epics serve one priority the leadership tracks	Themes become labels that no epic is measured against	Delivery detail, which belongs lower down

The row that causes most confusion is the project. An epic can run inside a project or across several of them, and the two should never be used interchangeably. The epic answers what outcome we are after, while the project answers when and at what cost we will reach it.

Writing an epic that a planning meeting can use

1. Write the outcome as a statement a sponsor could confirm, such as a change in how a process behaves for the people who use it.
2. Name the teams that will contribute and the one team that will be accountable for completion.
3. List the open decisions as their own items, each with an owner and a date by which the decision must be made, so the epic can start without pretending everything is known.
4. Break the work into stories only for the decisions that are settled. Leave the rest as a single placeholder story that marks where the next breakdown will happen.
5. Agree the completion test before the first story starts, and write it on the epic so that the closing decision is not left to memory.
6. Review the epic at each planning point and remove any story that no longer contributes to the stated outcome.

Where epics drift

An epic drifts when the outcome changes but the title does not. A program that started as a request for faster approvals can become a platform rebuild, and the epic still says approvals. The stories then describe work that no longer matches what the sponsor expects. The fix is to rewrite the outcome the moment it changes, and to close the old epic and open a new one if the change is large enough to affect the commitment.

A second drift appears when stories are created in one tool and the epic is maintained in another. Progress then looks stalled at the epic level while the stories show movement, and the sponsor loses confidence in the numbers. Keep the epic and its stories in the same record system, and make the rollup rule visible so that everyone reads the status the same way.

Telling whether the epic is doing its job

A working epic changes the conversations that happen around it. Sponsors ask about the outcome rather than about the count of stories. Teams can say which open decision blocks them, and the decision is made within the date set for it. Track the number of open decisions that pass their dates, and the number of stories added without a reference to the outcome, because both signal that the epic is being used as a dumping ground. Measure progress by the decisions made and the outcome checks passed, not only by the closed stories, since closed stories can still leave the outcome untouched.

When an epic is the wrong structure

An epic adds overhead, and that overhead is not worth paying for small, well understood work. If the team can describe the outcome in a sentence, has one group doing the work, and expects to finish within a single release, a story or a small set of stories is enough. An epic is also the wrong tool when the real need is a plan with fixed dates and a budget, because the epic will not enforce those commitments on its own.

Harder questions about epic governance

Who approves closing an epic?

The sponsor should, against the completion test written at the start. A team that closes its own epic has an incentive to define completion narrowly, so keep the closing decision with the person who owns the outcome, and record the evidence used to make it.

Can one story belong to two epics?

It can, but it should be rare. A story that serves two outcomes is often a sign that the outcomes overlap and should be merged or redefined. If the overlap is real, name the primary epic for accountability and the secondary one for visibility, so the story has one owner for its status.

How should an epic handle work that the organization has not yet decided to do?

Record it as an open decision, not as a story. Stories imply commitment, and a backlog full of uncommitted stories gives a false picture of the capacity needed. Keep undecided options on the epic as questions with owners, and promote them to stories only after the decision is made.

Next step

A review of the outcome statement and the open decisions can show what should be split, merged or closed.

The strategic portfolio and demand intake service covers how epics enter the portfolio, and the project portfolio governance service covers how they are tracked against the commitments the organization has made. The story concept shows the level below.