SCRUM - Epics that span multiple releases

[Chris York]

The SCRUM plugin for the Release module creates tables that are extended from planned_task. The way the relationships are designed appear to have an Epic (a group of work larger than a single story) as a child of a Release. And Stories can be setup as children of an Epic.

Product --> Release --> Epic --> Story

This structure works great if all Stories underneath an Epic are released at the same time. However, in the organization I am working with right now, Epics can be implemented across multiple releases.

What I would like to do is to have multiple Stories attached to a single Epic. Except that each Story could potentially be released on different releases.

From what I can see, this is not possible, but I was hoping the community could help me figure out a workaround.

[#2]

It doesn't help your immediate situation, but there's some work underway towards adjusting that model slightly to better support this.

Currently, you need to assign Stories to Releases/ Sprints and then the parent link to Epic is lost. You could adjust the related list to link Story to Epic via the "parent_feature" field, so that even when you assign the Story to a Release or Sprint (and therefore change the Story's parent) it retains the linkage back to Epic.

[Chris York]

Thanks James. What is the intention of the "parent_feature" field? If I use this reference field, I want to make sure I am not hurting myself down the road. The nice thing about the relationship at the parent level is viewing it on the Gantt Chart. Seeing the Epic, with all the children stories is visually nice. As soon as I link the Story to the Epic using another field, I assume I will lose this visual.

[#4]

You're right about the Gantt Chart view. Of course, it's meant to show "projecty things", the parent field being used for the project hierarchy, and an Epic isn't something you schedule.

The parent_feature field (inherited for rm_feature) was, I think, meant to allow modeling a "feature hierarchy", in parallel to the project hierarchy. It looks like the current "future direction" is not using that at all, but separately managing Epic, Sprint, and Release relationships of a Story. But that's all subject to change.