HKSM

Develop Epic(s) is the process of shaping large, high-value product initiatives into concise epic statements with business rationale, scope boundaries, and acceptance intent so they can be prioritized and later decomposed.

Purpose & When to Use

Use this process to capture big product ideas that span multiple Sprints or releases and are too large to be planned at the user story level. It creates a clear, shared understanding of the value, scope hints, and success measures so leadership can decide whether to invest and teams can later split the epic into features and user stories.

Trigger points include new strategic opportunities, regulatory mandates, major customer needs, or architecture/platform work that cuts across teams.

Mini Flow (How It’s Done)

• Identify opportunity and sponsor: gather signals from market analysis, customer feedback, compliance, or technology strategy.
• Draft the Epic Statement: name, problem/opportunity, target users, desired outcomes, success metrics, benefits hypothesis, constraints, and key risks.
• Outline value and size: record a rough cost/effort range (e.g., t‑shirt size or ROM), expected business value, time criticality, and risk reduction/enablement considerations.
• Define acceptance intent: high-level “how we’ll know” conditions and non-functional expectations; do not write detailed acceptance criteria yet.
• Map dependencies and assumptions: note affected systems, teams, vendors, and any gating decisions.
• Review and align: Product Owner (often Chief/Program/Portfolio PO) socializes the epic with stakeholders, refines based on feedback, and confirms alignment with vision and strategy.
• Decision and backlog entry: approve, defer, or discard. Approved epics are added to the program/portfolio backlog and queued for prioritization and later decomposition into features.

Quality & Acceptance Checklist

• Clear problem/opportunity and target users are stated in plain language.
• Measurable outcomes and success metrics are identified.
• Benefits hypothesis explains why the epic is worth doing.
• High-level scope boundaries and notable exclusions are captured.
• Rough size (ROM or t‑shirt) and value/time criticality are provided.
• Key dependencies, assumptions, and major risks are visible.
• Non-functional/quality considerations (e.g., performance, security) are noted.
• Alignment with product vision, roadmap, and budget guardrails is confirmed.
• Stakeholder alignment and Product Owner sign-off are documented.
• Epic is feasible to decompose into features within a reasonable timeframe.

Common Mistakes & Exam Traps

• Confusing epics with user stories: epics are option-level ideas, not Sprint-ready work.
• Writing detailed acceptance criteria too early; keep acceptance at intent level.
• Skipping the benefits hypothesis and success metrics, making value unclear.
• Estimating epics in story points or task hours; use coarse-grained sizing.
• Treating the epic as a fixed commitment instead of an investment option subject to review.
• Baking in solution design instead of expressing the problem and desired outcomes.
• Ignoring dependencies and non-functional needs, causing surprises later.
• Letting multiple epics overlap without clear boundaries, creating double counting of value.

PMP/SCRUM Example Question

During the Develop Epic(s) process, which action best ensures an epic is ready for prioritization at the program/portfolio level?

1. Break the epic into user stories with detailed acceptance criteria.
2. Prepare a short epic statement with problem, target users, measurable outcomes, benefits hypothesis, ROM size, and dependencies.
3. Build a working prototype to validate architectural feasibility.
4. Estimate the epic in team-level story points during Sprint Planning.

Correct Answer: B — Prioritization needs a concise epic statement, value hypothesis, coarse sizing, and visibility of dependencies; detailed stories, prototypes, and team-level estimates come later.