Looking for best planning options for Epics with Story Points

[Birgit Strompen]

I have a team and want to implement a handful of themes (epics) by a certain date.  To coordinate with other teams, we plan in "stages". The epics are either roughly estimated (based on historical values) or finely estimated because we have already worked out the associated stories. Estimation we do based on Story Points, which are noted in the Epic as a total. I would now like to craft the Epics in a timeline with several milestones so that they best fill the individual time periods. Is there a good editing option for this in Jira or a plugin or a completely different tool?

[Andrew Ching]

Are you using Jira Premium? If so - Advanced Roadmaps might be what you're after.  You can drive your timelines/plans in different ways (explicit start/end, estimate, sprint allocations etc.).  If you have hard dates, you could set these in your epic - it would highlight to you if your stories dates were outside of the Epic date range...

[Birgit Strompen]

Thanks Andrew, 

Advanced Roadmaps has not worked well for me so far. I determine the size of the epics based on the story points and Jira Roadmaps does not automatically convert them to a duration. At least I haven't found that option yet.
In the plan settings I had already entered,

"Estimation": Story points
"Inferred dates": None

But even if I try autoschedule, an Epic with 29 Story POints has the same duration (28 days) as an Epic with 49 Story Points. (The corresponding team has 30 Story Points Velocity for a sprint of two weeks).

[Andrew Ching]

The issue with Story Points is that they don't really represent a concept of time traditionally.  If you're using story points for time based estimating - have you considered switching to normal time based estimation.  That will drive your plan better in the way that you are describing?

[Birgit Strompen]

You are absolutely right. We are mixing apples and oranges. We want to keep the way agile teams work (estimating in story points - complexity, working in sprints) and still find a reasonably suitable time representation for classic management.

I still hope that others had similar problems and found a compromise solution