The Growth Project
Epics Are Dead: Planning When Work Ships in Days
We shipped a milestone last week in three days.
Not a feature flag. Not a spike. A real, in-production, customers-touching outcome. Planned Monday morning, live by Wednesday night.
The plan had a Project. It had Tasks. It had no Epic.
And nothing was missing.
What the Epic Was Actually For
Be honest about why the Epic tier exists.
It was never about the work. It was about the wait.
You had a strategy — a quarter’s worth of intent. And you had the smallest thing an engineer could pick up in a sprint. Between those two sat a chasm of weeks. The Epic was the scaffolding across it. A place to park the thesis while fourteen sprints of tickets ground through the backlog.
It answered a real question: “How do we keep this big thing coherent while it takes three months to build?”
You wrote the brief. You broke it into stories. You groomed it every fortnight. You re-estimated when reality moved. The Epic was a coordination tax you paid because delivery was slow.
It wasn’t a planning tier. It was a waiting room.
The Velocity That Broke It
Now the wait is gone.
When an outcome that used to take a quarter takes a week, the scaffolding has nothing to span. You’re building a bridge across a puddle. This is the same collapse we wrote about when we realised we were the bottleneck — the slow part stopped being the work.
Watch what happens to the Epic when delivery accelerates:
You write the brief on Monday. By Wednesday the work is in production. By the following Monday — your first grooming session — the Epic is describing something that already shipped. You’re refining acceptance criteria for code that’s been live for five days.
The Epic doesn’t speed up. It rots. It was designed to stay stable while slow work churned underneath it. Now the work outruns the document meant to govern it.
This is the part most teams miss. They keep the Epic and just move faster inside it. So they spend their new velocity grooming a tier that no longer holds anything. The tool built to manage the wait survives the death of the wait.
| What the Epic Assumed | What Velocity Changed |
|---|---|
| Big outcomes take months | Big outcomes take days |
| The brief outlives the work | The work outlives the brief |
| Grooming keeps it fresh | Grooming refines what already shipped |
| A tier to hold the thesis | A tier to maintain for its own sake |
| Decompose down into stories | Decompose down into tasks — directly |
The Three-Tier Model
Here’s what replaces it. Three tiers. Nothing more.
Project — the durable container.
This is the thing that doesn’t ship and doesn’t die. A customer engagement. A product line. A platform. It has a lifespan measured in quarters or years. It holds context, history, and the relationships between everything underneath it. The Project is the only tier that should stay stable, because it’s the only one describing something that genuinely persists.
Milestone — a shippable outcome with a thesis.
This is where the Epic’s job went. Not deleted — absorbed upward. The Milestone carries the why, the plan, and the acceptance criteria. The old Epic-brief now rides inside the milestone. The difference is lifespan: the Epic was a brief that had to survive months of slow work. The Milestone is a brief that ships before it can go stale. Same thesis. Radically shorter half-life.
A Milestone has a clear answer to three questions: Why are we doing this? What’s the plan? How do we know it’s done? If it can’t answer all three, it’s not a milestone. It’s a wish.
Task — the unit of execution.
The atomic thing that gets done. By a person, by an agent, by a pair of both. Tasks are cheap now. You can spin up ten and throw away seven. They don’t need the ceremony they used to, because the cost of getting one wrong dropped through the floor.
That’s the whole hierarchy. The collapse isn’t subtraction for its own sake. It’s that one tier’s function moved into another tier that does it better — which is exactly the systems-first move: don’t add a layer, fold its job into a primitive you already have.
The Brief That Stays Fresh
The real prize here isn’t fewer Jira levels. It’s living documents.
Every operator has felt the specific shame of the stale brief. The strategy document nobody reads because everyone knows it’s six weeks out of date. The acceptance criteria describing a version of the feature that no longer exists. The brief becomes fiction the moment the work diverges from it — and slow work always diverges.
A brief goes stale because there’s a long gap between writing it and shipping against it. The longer the gap, the more reality drifts. The Epic guaranteed that gap. It was structurally a long-lived brief.
Collapse the tier and you collapse the gap.
When the milestone’s thesis ships in days, the brief never gets the chance to lie. It’s written, it’s executed, it’s done — before the world moves out from under it. You stop maintaining a document and start spending it. Fresh by construction, not by discipline.
This is the part that sounds like a productivity tip and is actually a structural change. You’re not getting better at keeping briefs current. You’re removing the conditions that make them rot.
AI Changes the Shape, Not Just the Speed
The lazy reading of AI in engineering is “the same work, faster.” Type less, ship sooner.
That’s true and it’s the least interesting part.
The interesting part is that velocity past a threshold changes the shape of how you plan, not just the rate at which you execute. Structures that made sense at one speed become overhead at another. The Epic was load-bearing when delivery was slow. At speed it’s dead weight you’re still carrying.
We’ve seen this before. Batch releases made sense when deployment was a Friday-night event. Then deployment got cheap and continuous delivery made the release-batch obsolete — not faster, gone. Long-lived feature branches made sense when integration was painful. Trunk-based development — where everyone commits to one shared line of work instead of nursing separate copies for weeks — killed them when merging got cheap. Each time, a coordination structure built around a cost disappeared once the cost did.
The Epic is next. AI didn’t make it faster. It made the delay the Epic managed disappear. So the structure has nothing left to do.
Watch for the pattern in your own process. Anywhere you have a tier, a ceremony, or a document whose whole job is to keep things coherent while you wait — ask what happens to it when the wait is gone. Most don’t survive the question. Speed doesn’t just compress your timeline. It audits your structure.
First Thing Tomorrow
Stop grooming the waiting room. Start planning at the speed you actually ship.
- Find your slowest tier. Look at your hierarchy. Which level do you spend the most time maintaining relative to how much work it actually contains? That’s your Epic, whatever you call it.
- Ask what it holds. If the answer is “the thesis for work that’s still in the backlog,” ask how long that work really takes now. If it’s days, the tier is holding air.
- Move the brief up. Take the why, the plan, and the acceptance criteria out of the Epic and put them on the milestone. The milestone is now the smallest thing carrying a thesis.
- Time-box your briefs to your delivery speed. If you ship in a week, no brief should describe more than a week of work. A brief that outlives the work it describes is a brief that will lie to you.
- Delete the empty tier. Don’t migrate it. Don’t archive it “just in case.” Remove it. A tier that exists to be maintained will be maintained, forever, by someone.
The Bottom Line
Project holds the context. Milestone holds the thesis and ships before it goes stale. Task gets it done. Three tiers, because the fourth was only ever the wait.
The future of planning isn’t more structure to manage more speed.
It’s less structure, because speed dissolved the reason the structure existed.
Planning for a velocity your process wasn’t built for? We’ve rebuilt our own planning around how fast work actually ships now. That’s what we’d do for you. Let’s talk.