An Epic is a body of work that is too large or complex to be completed in a single Sprint. It typically needs to be broken down into smaller, more manageable stories or backlog items that can be tackled individually in shorter iterations. An Epic may span several sprints or even months, and as such, it often ties into larger product goals or milestones. But just like in any horror story, the trouble with these Epics is when they become “zombie-like”—forever unfinished and unclosed.
Possible Causes of Zombie Epics
One common reason Epics fail to close is hoarding. Teams may hold onto an Epic, fearing that they might need it later. This fear of closing an Epic too early and not having it available if needed can cause delays and create a backlog of uncompleted work. Another issue is the constant redefinition of scope—sometimes Epics grow larger over time, especially if the initial planning was too vague or the scope wasn’t well-defined from the start.
But the biggest culprit of all? Scope creep. When new features, requirements, or tasks are added to an Epic, it can continue to grow, making it harder and harder to close. Rather than being a discrete chunk of work, the Epic becomes an ever-expanding monolith, dragging down progress and preventing teams from focusing on what matters most.
The Five Levels of Planning: How Epics Fit into the Bigger Picture
Before we dive deeper into how to tackle zombie Epics, it’s important to understand how Epics fit into the larger planning framework within Agile. There are five levels of planning in Agile that help break down and manage work:
- Vision: The broad, high-level desired end goal for the product. What are we trying to achieve in the long run? This is the big picture that guides the overall product strategy.
- Roadmap: A strategic outline for the next 9-12 months, detailing major milestones and goals. Epics often form part of the roadmap, aligning the development effort with business objectives.
- Release Plan: A more tactical breakdown of what the team will deliver over several months. This often includes feature sets or Epics that contribute to the overall product goal.
- Sprint Plan: The plan for each individual sprint, detailing the specific backlog items (stories) that the team will work on during the sprint.
- Daily Standups: The day-to-day activity where team members report on progress, discuss roadblocks, and align on daily tasks.
Key for Epics:
Close the old, open the new.
Don’t Scope creep, make it small and discrete.
Scope creep doesn’t mean never, just not now.
Important Distinctions
A Product Goal is a high-level objective that guides the work for the team, and a Product Goal can contain multiple Epics. Each Epic represents a large chunk of work that contributes to achieving that goal.
One of the key rules of Agile development is never have Epics in the Sprint Backlog. Epics are too large to be completed in a single Sprint, so including them in the Sprint Backlog creates confusion and misalignment. Instead, break Epics into smaller stories that fit within a Sprint
Don’t abandon your work—keep it moving forward and close it out when it’s done. This helps prevent misalignment of priorities and ensures greater transparency across the team. If needed, you can always create future Epics for new tasks or features. However, leaving Epics open without closure can create significant impacts, such as bottlenecks, unresolved tasks, and unnecessary rework, ultimately slowing down progress and causing confusion.
Don’t let unfinished work stagnate and hold up progress. Focus on delivering small, discrete chunks of work that can be iterated upon and improved. Avoid scope creep, break down Epics into manageable pieces, and don’t let features or tasks pile up unchecked.
By keeping your Epics aligned with product goals, continuously iterating on them, and ensuring they’re small enough to be completed in a timely fashion, you can avoid the trap of zombie Epics and keep your Agile development moving forward.