Fewer epics with more stories or vice versus - Roadmap/StoryMap - Observation

[JosephF]

I am a big fan of Story Maps and am now tinkering with Roadmaps.  There seems to be a difference in these two approaches in that for Story Maps, it is beneficial to have fewer Epics with a longer running list of Stories through time showing your progress in achieving the Epic goals.

In Roadmaps, this yields one super long Epic without much detail.

I am doing M&A Integration and here is an example.  For the integration of the acquired team's email capability, there are several phases going from day-1 where you may have simple aliasing and branding done to a more comprehensive end-state solution with fully unified systems.

In Story Maps, I tend to put one Epic called 'Email' and have Stories going down through time starting with Day-1, Interim State and End-State.  (I use versions to represent the major phases of the integration such as week-1, month-1, first 90 days etc)  This gives a good view of what is happening and lets other Epics/Stories align with the efforts.

This approach does not work well with Roadmaps that will then have just one big epic called email.  Roadmaps prefers to have more detailed Epics for the equivalent scenario.

Just an observation.

[Nick Muldoon]

Hi Joseph, thanks for sharing.

We've been exploring the ability to chunk epics on the roadmap into different pieces. It would still be one epic for consistency with the JIRA view issue page and on the backlog, yet it would appear on the roadmap as several pieces.

In that scenario you could have Email chunked up into several pieces, one for each of the versions for the integration work.

The only drawback I can think of is that each of the pieces of the one epic would retain the same name, so that wouldn't help with the descriptive nature you're possibly seeking.

Eager for other customers to share whether the chunking would work for them and how they would use it.

Thanks Joe, have a great day,
Nick