Epic
An epic generator that writes the three things an epic needs: the one outcome it is for, what must be true before anyone can call it done, and the measure that would show it worked. Not a container with a title, which is what most epics are.
- Asks for
- What you are trying to achieve, in a sentence or two
- Who it is for and what they do today
- Anything already known about scope or constraints
- Gives back
- One outcome, stated as a change in the world rather than a deliverable
- Done-when conditions, each one checkable
- How you would know it worked: the measure and the direction
- Where the epic is really two, and where to split it
- Plan
- Free
- Use next
- User story, Document to tickets, PRD, Roadmap
What it gives you
Epic — A new user can get a ranked backlog in their first session. Done when — A CSV of 10–500 rows imports without a manual mapping step. — A row with missing data is reported, not rejected with the file. — The ranking appears before anything is saved. How we would know it worked Share of new signups reaching a ranked backlog in session one: 22% → 45%. Probably two epics: import and ranking have separate done-when lists.
How it works
An epic is used as a folder in most backlogs — a name that stories get dropped into, with no statement of what finishing it would change. The consequence appears at the end: nobody can say whether it is done, so it stays open for two quarters and gets closed when someone tidies the board.
So this writes the outcome first, as one sentence about the world rather than the software, and then the done-when conditions: the things that have to be true, each of which somebody could check. Those conditions are what make the epic closeable, and writing them up front usually reveals that the epic as conceived is two epics.
The measure is the third part and the one most often skipped. How would you know it worked — which number, moving which way, by roughly how much. Without it an epic can be fully delivered and entirely pointless, and nobody finds out, because there was nothing it was supposed to move.
Who it is for
A PM about to open an epic in Jira who wants it to be closeable, and a team that would like to know what finishing it is supposed to change.
Where it stops
It writes the epic; it does not break it into the stories underneath — Document to tickets or User story does that. And it cannot tell you the outcome is worth wanting: a well-formed epic for the wrong quarter is still the wrong quarter.
Questions people ask
What is the difference between an epic and a story?
An epic is one outcome that takes more than a sprint and more than one person to reach; a story is a slice of it small enough to build, test and release on its own. The useful test is the done-when list: if you can write conditions that are all checkable and it still cannot be finished in a sprint, it is an epic. If one person could do it this week, it is a story and wrapping it in an epic adds ceremony.
Why does an epic need a measure?
Because without one it can be delivered completely and change nothing, and nobody will notice. The measure does not have to be precise — a number, a direction, a rough size is enough — but it has to exist before the work starts, because a measure chosen afterwards is chosen to flatter the result. It is also the fastest way to find out that an epic nobody can attach a number to may not be worth a quarter.
How do I know if my epic is too big?
If the done-when conditions split cleanly into two groups that do not depend on each other, it is two epics, and this will say so. The other signal is a condition you cannot check — anything phrased as an improvement rather than a state. Big is not the problem on its own; an epic that genuinely takes a quarter is normal. Unsplittable and unmeasurable is the problem.
Run it on your own work
Epic needs an account, because it writes against what you give it and remembers what you have told it before. It runs on the Free plan. Or see what the plans cost first.