Question 1

What's the difference between an epic, a user story, and a task?

Accepted Answer

These are three levels of the same hierarchy. An epic is a large strategic initiative that may take weeks or months — for example, 'Add team collaboration.' A user story is a specific feature from the user's perspective that fits within a sprint — for example, 'As a user, I can invite a teammate via email.' A task is a technical step within a user story — for example, 'Create /invite API endpoint.' Epics contain stories; stories contain tasks. Each level gets progressively smaller and more executable. Most agile tools (Jira, Linear, Shortcut) model this hierarchy natively.

Question 2

How big should an epic be?

Accepted Answer

A well-sized epic typically takes 2–6 sprints (4–12 weeks) to complete, contains 5–15 user stories, and represents a meaningful business outcome. If an epic can be completed in a single sprint, it's probably a user story. If it would take a full quarter or longer without clear milestones, break it into multiple epics. The test: can your team articulate what success looks like for this epic, and would a stakeholder care about the outcome? If yes, it's probably the right size. Epics should be big enough to matter strategically but small enough to ship incrementally.

Question 3

How do I write a good epic for my product team?

Accepted Answer

A strong epic includes: (1) A clear name that describes the business outcome, not the feature — 'Improve trial conversion' not 'Build onboarding flow.' (2) A brief narrative explaining the problem being solved and why now. (3) Acceptance criteria defining what done looks like at the epic level. (4) A list of known user stories with rough estimates. (5) Dependencies and risks. (6) An owner responsible for driving it to completion. Start from the customer problem, not the solution. The epic should answer: what problem does this solve, for whom, and how will we know it worked?

Question 4

What's the most common mistake founders make with epics?

Accepted Answer

The most common mistake is making epics too vague or too large — essentially using them as dumping grounds for related work with no clear definition of done. This creates what teams call 'zombie epics' that never close and accumulate stories indefinitely. The second most common mistake is skipping epics entirely and tracking everything at the story level, which makes it impossible to see strategic progress. Fix both by requiring every epic to have an owner, a goal statement, and exit criteria before adding any stories. If you can't define when the epic is done, it's not ready to be an epic.

Question 5

How do epics relate to a product roadmap?

Accepted Answer

Your roadmap is the strategic view of what you're building and when; epics are the execution unit that maps to roadmap items. A roadmap shows 'Q2: Improve retention' — an epic translates that into 'In-app onboarding checklist' with concrete stories. Well-run product teams maintain a two-way link: every epic ties to a roadmap goal, and every roadmap goal has at least one active epic. This prevents roadmap theater (strategy that never ships) and directionless execution (coding without strategic purpose). Epics also give stakeholders a way to track progress against roadmap commitments without needing access to your issue tracker.

Question 6

Do startups with 2–3 engineers need epics?

Accepted Answer

Small teams benefit from lightweight epics even without formal agile tooling. The value isn't the process — it's the discipline of grouping work around outcomes. A 3-person team building a 'billing system' can use a shared doc or a simple project board to group their stories under a single epic goal. What matters is that everyone knows which bigger initiative each piece of work connects to. Without that, small teams frequently ship unrelated features and struggle to articulate progress to investors or co-founders. Scale the formality to your team: a post-it wall works; a formal epic template is optional.

Question 7

How do epics fit into a dual-track agile workflow?

Accepted Answer

Dual-track agile runs discovery and delivery in parallel. In the discovery track, epics are often born as problem statements or opportunity hypotheses — the team validates whether the epic is worth building before writing stories. In the delivery track, validated epics get broken into stories and enter the sprint backlog. This prevents the classic mistake of building a well-structured epic for the wrong thing. Epics in dual-track agile often have a 'discovery phase' with its own acceptance criteria (e.g., 'validate that 5 customers would pay for X') before transitioning to 'delivery phase' with user stories.

Question 8

Where did the concept of an epic come from in software development?

Accepted Answer

The term 'epic' in software development emerged from the Extreme Programming (XP) and Scrum communities in the early 2000s as teams struggled to manage large features that didn't fit within a single sprint. The metaphor borrows from storytelling — an epic is a grand narrative made up of many smaller stories. Mike Cohn's work on user stories and agile estimation helped popularize the term in the 2000s. It was later institutionalized by tools like Jira, which added 'Epic' as a formal issue type around 2009–2010, cementing the vocabulary across the industry.

Epic

Definition

Example Usage

Common Misconceptions

Related Terms

User Story

Sprint

Product Roadmap

Story Mapping

Scrum

Agile

Related Tools

Frequently Asked Questions about Epic

Explore More Resources

Browse Tools

Build Your Stack

Recommended Reading

Listen & Learn

Help us improve this definition

Help us improve this page

Stay in the loop