Skip to main content

Epic Roadmap

An Epic Roadmap is a lightweight product roadmap and is a technique for planning and tracking agile delivery. It consists of a list of epics in the order we intend to deliver them, and grouped against the sprint or month in which we expect to deliver them, and is a valuable tool for making agile deliveries more predictable.

What is it for?

What? Give early visibility of whether the team is the right size to deliver the desired features within the time available. Why? So early corrective action can be taken, e.g. reconsider priorities, adjust expectations, allocate more time or people to a team or allocate whole additional team(s).

What? Focus on delivering business value incrementally, starting with the highest priorities. Why? To minimise the impact of possible overrun and maximise our ability to learn from user feedback. If we run out of time, we want to have delivered the most valuable things, not have left them to the end.

What? Identify and visualise dependencies between teams. Why? To allow dependencies to be avoided or planned around.

What? Give the big picture of what we're building and identify delivery milestone goals. Why? To know where we're heading without getting lost in the detail of an endless list of stories. To get a real measure of progress we can trust.

What? Help identify risky epics to allow them to be prioritised early, and encourage us to plan the tasks needed in the run up to go-live. Why? To reduce the risk of nasty surprises late in delivery derailing the timeline.

What? Determine the immediate focus for just in time analysis and elaboration, ready for the next sprint. Why? So that the team never runs out of items with requirements which are understood well enough to be ready to deliver.

How do you do it?

  1. Start with a vision of the expected outcomes. This should come from your product owner or other stakeholders.

  2. Identify themes, epics and stories. Use a lightweight lo-fi process: whiteboard and post-it notes, not electronic. Epics and stories should follow the INVEST principle. The epics are the most important item here, and will be the only thing we keep from this process; the themes and stories are only tools to help identify and understand the epics.

  3. Assign very rough relative sizes to epics. Use points (1, 2, 3, 5, 8, 13, ...) or T-shirt sizing (XS, S, M, L, XL) and high/low complexity indicators. Split or combine epics to better follow INVEST. Make a brief note of the stories identified for each epic and key assumptions or exclusions, but don't put them in your issue tracking system yet: they will almost certainly be stale by the time the team is ready to deliver the epic.

  4. Determine interim goals to deliver your product incrementally. Express goals in terms of business benefit, with quantitative metrics to determine whether the goal has been achieved. Write one sticky note for each epic and group epics against the goal they contribute to. Keep actively refining your epics, splitting them if needed to keep focus on delivering maximum value early. Forecast an expected delivery date range for each goal. Product roadmap

  5. As delivery progresses, the team will better understand its delivery rate and learn more about the problem domain. Periodically review and refine the epics which contribute to each goal and the predicted delivery dates. Through this process, epics are expected to be created, removed, joined and split, but the goals they contribute to should be relatively stable.

Do and Don't

Do include your product owner or key stakeholders in the formation of the Epic Roadmap, including estimation sessions, so they can answer questions and clarify assumptions. Don't create the roadmap and present it to the PO. They will be able to clarify and change key assumptions if they are involved, and if the scope doesn't fit the team and time available, they need to be bought into the process that predicts this.

Do understand that an Epic Roadmap is a prediction based on the information available at the time. Don't treat the roadmap as a promise. Don't dismiss the roadmap if it tells an unwelcome story.

Do create an Epic Roadmap before you start implementation. Don't start implementing without the guidance the roadmap gives on what to build first.

Do use spikes and lo-fi prototypes judiciously just enough to allow epics to be T-shirt sized. Don't invest a lot of effort in trying to determine "accurate" estimates or understand every unknown business requirement or technical implication.

Do schedule epics which clearly have high business value early. Don't schedule poorly understood epics early: split them into a "basic" implementation which is scheduled early and an "enhanced" flavour delivered later, when we will better understand its detail and value.

Do periodically revise your estimates and the running order in light of new information like user feedback and increasing technical understanding. Don't treat the roadmap as set in stone.