Rename Epic as as Feature in Jira cloud

Question

I have a business need where the 3 level Hierarchy of Epic->Story->Sub Task will not work for us. I know Jira will not let me introduce Feature between Epic & Story without a plugin.

I have Jira Cloud Premium subscription so i can add hierarchies in Advanced Roadmap.

If I rename Epic as Feature and add Epic on top of that, will this break Jira?

At this point, I am not inclined to go with any plugins as every functionality we think of seems to be needing a plugin (for instance granular time reporting).

Any suggestions will be helpful as we are in the process of rolling out Jira for my team.

Matthew Day_7dgif0 · Answer

@Konstantin Nazarov / @Vishal Biyani -> Agree as I'm in the same boat.

The problem is that the default Jira board for everyone is Active Sprint, which will ONLY show Jira default items (i.e. Epics & Atlassian default types like story, task, subtask).

I created a new Issue-level called 'Dependency' so that an Epic in one project would reflect the external dependencies better than linking tickets. Worked great in testing until we actually kicked off our SAFe Program Increment with the first sprint. There was no way to get that ticket type to show in the Active Sprint board - trust me, I tried. They did show up in the Backlog view for the current sprint, but many non-technical people found that confusing.

Same issue with Jira Premium when creating Hierarchy level tickets (in Advanced Roadmaps). I was able to create 'New Feature' as an Epic-level item, but it won't show in the classic views of the Jira Board.

As more Atlassian customers adopt SAFe, I'm sure things will become available, but for now, it's a bit limiting.

The Plan view (Jira Premium - Advanced Roadmaps) may be a different/better way, but I didn't get things implemented in time for our next PI, which kicks off soon.

Konstantin Nazarov · Answer

Bishal, could I ask you a question?

If Features in your business are Agile Features (SAFe, as Darrel Jackson said), then is it correct to talk about the hierarchy level? After all, Features are kind of a general requirement for a certain amount of Story or Epics. What if you have an intersection of Features for Storys, Epics? If we represent Features not as a parent class in the OOP hierarchy, but as an object with properties, such that a link from Story and Epic can be established with this object? Then Jira allows you to do it (that is, not as a derivation from the parent object, but as a constant assignment).

For example, if you generate a new type of object of the same OOP level with Story and Task, name it Features, create a list of labels for it (that will describe Features), set link to the best selected link type to Story vs Features, then the Agile structure can be described as hierarchical without applying the hierarchy of objects at the Object level OOP code Jira. The downside is that you have to control mistakes, and the plus is that Jira allows you to cross "snake with a hedgehog, and get half a meter of barbed wire" (an old joke about combining incombinible, such as link Epic dipended by story, who is child from this Epic no recursion:)). Why is there an OOP hierarchy here?

I point out to myself that Jira has a lot of creative freedom for the project manager. Jira does not have strict rules, (which are occure in PTC products, for example), and in Jira you can build any hierarchy, with one drawback that the system allows you to do almost everything. What the system allows you to do, it does not link with predefined programm rules, OOP hierarchy, and the minus is that human errors are possible and require control.

Subtasks, as they are implemented in Jira, do not suit me either (IMHO, subtask in Jira is not OOP object), but Jira allows you to create objects of the same level with story and task, as new entities, or as a new class, and you can already establish links with them through “Linked issues”. Of course, this is not a programmatic rule, and errors are possible but it establish at least 10 hierarchy levels that will require compliance with the rules described on paper.

At the same time, Epics allows you to put yourself in any dependency, place them in parallel, independently of one another. Allows you to build hierarchy levels in one class. If you do not change the name of the Epic class, but only enter a prefix for epics name for your different hierarchy levels, then you can also build at least 10 hierarchy levels in the epics themselves. It's just that epics allow you to set dependencies on epics. The downside is that such actions require regulations, but the plus is that regulations can be written with any number of hierarchy levels, since Jira does not prevent this.

In Jira, you can stretch one Epic in product size, others in sprints size, and still others in story and task sizes. Add to Epics as Features. I'm not saying that this should be done and it is good decision, but Jira allows it. For why rename Epic class/ add new class if everything is already working with 1 Epic class? What type of problem can I face in Jira, if I implement dependencies the way I described?

Darrel Jackson · Answer

It's not advised to rename the Epic issue type. Lots of stuff breaks. There are plugins to minimise what breaks but not supported in Cloud as far as I'm aware.

Jira works with a 2-tier system, (ignoring subtasks that is) with multiple tiers using Advanced Roadmap. But that 2nd tier is always named Epic.

If you're trying to implement the SAFE requirements model (Epic -> Feature -> Story or Epic -> Capability -> Feature -> Story) there are a few options:

1. You could Issue links instead (i.e. Epic -> Feature & Epic -> Story using Epic links and Feature -> Story using Issue Links). Accurate model but usability issue visualising Feature -> Story link and maintaining Feature -> Story link.

2. You could use separate projects using fake Epics as Features (Feature-based project has Epic -> Feature, Story-based project has "fake" Epic -> Story and "fake" Epic is linked to Feature. Not good for users as you need to understand the "fake" Epic is a feature. Good if your Features use Stories from multiple projects though.

3. Use a tool designed for SAFE requirements modelling instead.