When you’re working at the portfolio level in Agile, it’s easy to get tangled up in the weeds of epics. Large-scale initiatives can feel overwhelming if you’re not sure how to break them down or where they stand in the bigger picture. It’s not just about moving a story from “To Do” to “Done” on a Kanban board. At this scale, it’s more like navigating a roadmap of epics that need to be funneled, reviewed, analyzed, prioritized, implemented, and ultimately completed. The SAFe framework wraps all of this up nicely with the FRAPID model, which breaks an epic’s journey into those stages: Funnel, Review, Analyze, Prioritize, Implement, and Done. So, how does this model help keep your epics on track without turning things into a bureaucratic nightmare? Well, it starts with understanding how each stage plays its role in managing the lifecycle of an epic.

First off, let’s talk about the Funnel. Think of this as the intake process for your ideas. Whenever someone in the organization pitches a large-scale change or initiative—whether it’s about launching a new product or restructuring an existing system—it gets tossed into the Funnel. There’s no filter at this stage, no judgment about whether the idea is good, practical, or even realistic. The goal here is to create a space where innovation can find its footing. The challenge? Being selective about what you move forward with. In some teams, I’ve seen funnels become these massive graveyards for every idea that’s ever come up, but that’s not what we’re trying to do. It’s about making sure we give thoughtful attention to the best stuff without letting the board become noise.

Once an idea gets out of the Funnel, it’s on to the Review stage. Here, things start to get a little more serious. You’re involving key stakeholders and decision-makers to determine if this epic aligns with the broader business objectives. The trick is in getting the right people in the room (or Zoom call) and being brutally honest about whether or not there’s real potential. At this point, an epic might be deemed “not now,” which is perfectly fine. It’s always better to let something sit on the backburner if the timing’s not right than to force it down the pipeline just because it seems important today.

Now, the Analyze stage is where it gets interesting. This is the deep dive. You’re not just asking, “Should we do this?” You’re asking, “Can we do this, and is it feasible with the resources we have on hand?” Agile teams often struggle here because it can feel almost like you’re returning to heavy planning days. But here’s the catch—Agile isn’t about avoiding planning; it’s about planning just enough to make sure you’re heading in the right direction without getting paralyzed by analysis. During this phase, you’re looking at budgets, timelines, technical risks, and, importantly, the value that this epic will bring to the customer. Agile teams and Lean Portfolio Management (LPM) work closely here to ensure it’s balanced. You want to be prepared, but you also want to stay nimble enough to pivot if you discover something down the line isn’t viable.

Getting into Prioritize mode is often where the heartburn kicks in. There’s only so much an organization can focus on at once, and every epic can’t be number one. Prioritization involves tough calls, and if not done collaboratively, it can lead to resentment or confusion within teams. The goal in this stage is to decide which epics to move to implementation based on value, strategic alignment, and available resources. Sometimes technical debt epics might come into play here, and those are the ones that often get tricky—teams might resist prioritizing them because they don’t feel immediate, but overlooking this work usually leads to messier issues down the road. And trust me, tech debt doesn’t go away if you just ignore it.
Once an epic makes it into the Funnel in SAFe’s FRAPID model, we’re officially looking at “potential work.” But, and this is a big but, just because it lands in that stage doesn’t mean it’s a done deal. In fact, most epics won’t make it out of this early phase. Agile organizations have to stay vigilant here—this is where the initial validation happens. Teams (and by teams, I mean cross-functional groups that include stakeholders beyond just development) need to ask the right questions up front: should we invest time and resources into analyzing this further? Does it align with our broader business goals?

Once the initial gatekeeping happens, the epic moves ahead for review and analysis, assuming it passes. The Review stage is all about diving deeper and getting a clear idea of potential business and technical impacts. Now, this is where people often rush too much because the temptation to “just get moving” looms large. But good Agile practice isn’t about moving for movement’s sake. This is where Product Managers, Architects, and Portfolio Managers should come together to assess the feasibility, scope, and strategic alignment of the work. Creating a lightweight business case is key here—not a huge project brief, but enough of a structure that decision-makers can prioritize intelligently.

After a review, we move into what I think of as the true investigation phase: the Analysis stage. This is when we dissect the epic, slice and dice it into MVPs (Minimum Viable Products) or identify where breaking it into smaller manageable chunks makes sense. Teams explore different scenarios and begin to think about rough timelines and impact. And by “teams,” I don’t just mean engineers—this whole exercise should see input flowing from marketing, operations, security, and any other functions who’ll feel the ripple effects of this work. It’s easy to underestimate how one epic’s completion might dramatically shift resource allocation across the organization, so transparently analyzing that is crucial.

After all that effort, the next part can either be very rewarding or frustrating, depending on how strong leadership collaboration is: implementing the epic. This is the part that feels familiar for Agile development teams—at this point, tasks become concrete, backlogs get filled, and teams work in iterations towards achieving milestones related to the epic. But even here, a few traps are worth avoiding. Often Agile teams, when they finally start something they’ve worked hard to prioritize, assume it’s now set in stone. Not so fast. True Agile implementation means staying open to shifts in customer feedback, unexpected technical hurdles, or shifts in business strategy. It’s not about stubbornly sticking to the original scope.

One trick I’ve found to be especially helpful is setting clear decision boundaries. If mid-implementation, there’s a major change that pops up (like a competitor beating you to the market), the team knows exactly who to inform and bring into the next discussion. Decision boundaries prevent your day-to-day work from spiraling into delay decisions, and they’re especially key for keeping executive input at the right level—influential but not disruptive.

After the majority of those iteration cycles complete and the epic objectives are met, we then move into, what I call the somewhat underrated phase of completion—Done., The Done phase isn’t just about marking something off the to-do list. It’s the final opportunity to evaluate whether the epic delivered the value it promised. Reflect on the ROI not just in dollars but in technical and operational fitness too. Retrospectives are critical here. Did it make sense to take this work on over others? What did the team learn? Those learnings can influence future epics before they even hit the Funnel again, creating an invaluable feedback loop for improving how teams select and work on large initiatives.

Of course, managing epics in this structured way doesn’t always go off without a hitch. Everyone who’s worked in scaled Agile environments knows that epics can easily drag out longer than expected or run into issues around resource bottlenecks or stalled decision-making. One challenge I’ve seen repeatedly is teams struggling to distinguish between what needs to be handled as an epic versus what could be better tackled with smaller stories or features. Sometimes, we can fee like we’re stuck in “Analysis Paralysis,” pumping too much into research phases without realizing that parts of the work could have been iterated on all along.

Adding to that, cross-functional collaboration during stages like Review and Analyze often falters when teams fall back into silos, thinking, “Well, marketing will be involved later,” or, “We don’t really need to bring ops into this decision right now.” But the truth is, those early conversations with a diverse set of voices can prevent much bigger rework headaches down the line. You don’t want the Operations or Security team stepping in during implementation, telling you things aren’t feasible after the train’s halfway down the track.

In the end, epics represent more than just big pieces of work—they’re complex solutions built to deliver strategic results. Managing them thoughtfully through their lifecycle—from Funnel to Done—helps create that alignment across multiple teams and roles, even in high-paced, dynamic environments. And as I’ve noticed over and over again, when teams can manage epics successfully, they start to solve bigger problems more sustainably, with fewer rushes under pressure and fewer missteps.

So, whether you’re analyzing the ROI of a proposed feature, slicing an epic up into deliverable increments, or finally kicking off that long-awaited project implementation, understanding the lifecycle of an epic ensures that your Agile teams are empowered to deliver maximum value without losing that critical flexibility.

By honing in on best practices within each phase, with strong collaboration and transparency, Agile teams can truly start to connect dots between portfolio strategy and operational output, one epic at a time.