Epics from meetings

Epics that hold their stories together.

Some things said in meetings are bigger than a ticket. A rollout, a phase, a capability with four moving parts. Backlog.cloud hears the scale, drafts the epic with its goal and scope boundaries, and attaches the child stories from the same conversation underneath it. You review the structure, then push it whole.

What an epic is

Structure above the story level, with an actual finish line

An epic is a goal that takes several stories to deliver. Not a category, not a label, not a place to sweep tickets that lack a home. It has a goal you can state in one sentence, a boundary that says what is out of scope, and an end. When the goal ships, the epic closes.

The useful test: could one team finish this inside a sprint? If yes, it is a user story. If it takes a quarter and decomposes into distinct deliverables, it is an epic. If it never really ends, like "improve warehouse efficiency", it is a theme, and a theme belongs in your portfolio conversation, not your backlog.

Meetings are where epics are born. Someone describes the big thing, someone else breaks it into parts, a third person rules something out of scope. All the structure is right there in the audio. The problem is that most teams walk out with four sticky notes and rebuild that structure from memory two days later, badly.

Before and after

A rollout conversation becomes an epic with four stories

Five lines from a fictional project kickoff for a warehouse management rollout, and the epic Backlog.cloud drafts from them. This is a curated demonstration of the real output shape.

What was said

Marta (PM): The Leeds warehouse goes live on the new stock system in Q3, and nothing about receiving goods works the same way. Scanning, putaway, the lot.

Owen (Eng): Receiving is at least four separate pieces. Scan on the dock, assign a putaway location, exception handling for damaged pallets, and the label printing.

Marta (PM): Dispatch is out of scope for this phase. Leeds keeps the old dispatch flow until January, so do not let anyone drag it in.

Owen (Eng): Scanning has to land first. Putaway suggestions are pointless if the dock team is still keying in barcodes by hand.

Ines (Ops): And the dock printers are the ancient Zebra units. Whatever we build has to print to those, we are not replacing hardware this year.

Highlighted statements are the ones the extraction engine anchored the epic to.

Epic4 child storieswarehouse-rollout

Goods receiving on the new stock system for Leeds

Replace the manual receiving flow at the Leeds warehouse with scanning, putaway suggestions, damage handling and label printing on the new stock system, ready for the Q3 go-live.

Scope boundary

In: dock scanning, putaway, damaged-pallet handling, label printing to existing hardware. Out: dispatch, which stays on the current flow until January.

"Dispatch is out of scope for this phase. Leeds keeps the old dispatch flow until January, so do not let anyone drag it in."

Child stories with sequencing

  1. 1. Scan inbound pallets on the receiving dock

    First. Everything downstream depends on scanned data.

  2. 2. Suggest a putaway location after a pallet is scanned

    After scanning. Needs live stock positions from scans.

  3. 3. Flag and quarantine damaged pallets at receiving

    Parallel with putaway. Shares the scan flow.

  4. 4. Print putaway labels to existing dock printers

    Last. Formats output from the two flows above.

Each child story carries its own description, numbered Gherkin acceptance criteria and source quote. The epic is the frame. The stories do the delivering.

Anatomy

What a generated epic contains, and why each part is there

Goal statement

One sentence naming the outcome and, where the conversation gave one, the deadline that makes it real. Written so a person joining the project in month two understands why the epic exists without asking anyone.

Scope boundaries

Explicit in and out. Exclusions get captured verbatim because they are the part teams forget fastest and argue about longest. "Dispatch stays out until January" is worth more written down than any feature list.

Child stories

The stories extracted from the same conversation arrive already attached. Each one is a full INVEST story with its own acceptance criteria, not a bullet point. Stories from later meetings can be attached during review.

Sequencing hints and evidence

When someone says "scanning has to land first", that ordering is recorded against the epic. And every part of the artefact links back to the verbatim quote it came from, so a reviewer can check the source in seconds.

Getting the level right

Epic, story or theme? The three-question test

Most epic confusion is level confusion. Backlog.cloud applies the same test a good product owner does, and you can overrule it in review.

QuestionStoryEpicTheme
Does it end?Yes, in a sprintYes, in a phase or quarterNo, it is a standing focus
Does it decompose?No, it is the unitInto storiesInto epics
Who owns it?The team, this sprintThe team, this phaseThe portfolio

Work that is genuinely uncertain rather than genuinely big is a different artefact entirely. That is a spike, and it gets a time-box, not child stories.

Destinations

Where the epic and its stories land

After review, the epic pushes to your work management platform with the parent-child links intact. No copy-pasting story keys into an epic description by hand.

Jira

Epic issue type

Child stories arrive linked to the epic, descriptions in Atlassian Document Format, priority and labels mapped to your scheme.

Azure DevOps

Epic or Feature work item

You choose the level per project. Child items land with area and iteration paths respected.

Linear

Project with linked issues

Linear has no epic type, so the epic becomes the project that groups its issues.

GitHub Issues, Notion, ClickUp

Closest native grouping

A tracking issue, a database entry, or a ClickUp list. The parent-child relationship survives the push.

Common mistakes

How epics go wrong, in the wild and in tools

Epics as junk drawers

An epic named "Warehouse stuff" that collects every loosely related ticket is not structure, it is a folder. An epic needs a goal you can finish. If you cannot say what done looks like, it is a theme wearing an epic costume.

No scope boundary

The most useful sentence in an epic is the one that says what is out. Marta ruled dispatch out of phase one in the meeting. If the epic does not record that, someone will scope-creep dispatch in by November and the Q3 date dies quietly.

Writing the epic after the stories

Teams often draft twelve stories, notice the sprawl, then invent an epic to contain them. Backwards. The epic existed in the conversation first, as the big thing someone described. Capture it there and the stories inherit a shape instead of imposing one.

Epics with one story

If everything fits in a single story, it is a story. Promoting it to an epic adds a layer of hierarchy nobody needed and makes the board lie about how much structure the work has.

Sequencing left in one head

Owen said scanning has to land first. Said out loud, obvious. Three weeks later, with a new joiner picking up putaway, invisible. A sequencing note on the epic is cheap insurance against building things in the wrong order.

Not sure what to ask in the room so the epic comes out clean? There is a full list of good questions to ask before writing an epic on the blog.

FAQ

Epics, answered

What is an epic, exactly?
A body of work too big for one story but with a definite goal and a definite end. It groups the stories that deliver that goal, records what is in and out of scope, and gives the backlog a level of structure between "everything" and "one ticket". When the goal is met, the epic closes.
How does Backlog.cloud know something is an epic and not a story?
Scale signals in the conversation. When someone describes an outcome that clearly decomposes ("receiving is at least four separate pieces"), names a phase or milestone, or draws a scope boundary, that is epic-shaped talk. A single concrete capability with one acceptance path stays a story. The reviewer can always demote or promote before pushing.
What is the difference between an epic, a story and a theme?
A story is one deliverable slice of value, finishable in a sprint. An epic is a goal delivered by several stories, finishable in a quarter or a phase. A theme is a standing area of investment, like "warehouse efficiency", that never really closes. Backlog.cloud generates stories and epics. Themes are a portfolio conversation, not an extraction target.
Do generated stories automatically attach to the epic?
When stories and the epic come from the same conversation, the stories arrive in the review queue already grouped under it, and the parent link is included in the push. Stories generated later from another meeting can be attached during review before they go anywhere.
What fields does a generated epic contain?
A goal statement, a scope section with explicit exclusions, the list of child stories, sequencing hints where the conversation implied an order, and the verbatim quotes each part was anchored to. It lands in the review queue like every other artefact, so a human approves it before it reaches your work management platform.
Which meeting types produce epics?
Any conversation where big work gets shaped: project kickoffs, PI planning, sprint planning, backlog refinement and discovery workshops most often. Backlog.cloud knows the meeting type and listens accordingly, so a retro does not suddenly sprout epics.
Can I push an epic to Jira with its stories in one go?
Yes. The epic pushes as a Jira Epic issue and the approved child stories push linked to it, descriptions converted to Atlassian Document Format. Rate limits are handled with batching and backoff, so a big planning session lands completely.

The epic was in the meeting. Keep it.

Create a free account, run Backlog.cloud on your next kickoff or planning session, and review the epic it drafts with the stories already attached. 3 free generations, no card.