Custom issue hierarchy

[Julien REBILLARD]

Hi,

I use a premium plan and therefore have the ability to create my own ticket hierarchies.
In my organization, we receive a request in JSW from JSM, in our agile organization, we split this initial request into Epic, Story to initiate our sprints.

So I created a hierarchy:
Initial request (Dev, Evo, ...) > Epic > Story> Subtask, combined with the use of the new parent field.

In the case of a small request, I do not necessarily need the Epic level, and I want to directly attach a story to an initial request,.

Jira requires respecting the hierarchy and does not allow a story to be attached to another request what does an Epic have?

I also tried upgrading the initial request to Epic level : Epic > Story > Subtask.

but in this case I can no longer attach Epic to a request because it is at the highest level.

Am I obliged to stay in the Epic > Story > Sub task case and manage the Initial request > Epic link using a dedicated type of link, and do without the use of the parent field (therefore double management of parent tickets in the automaton ...)?

Thank you in advance for your feedback

[John Funk]

Hi Julien,

Why are you putting the initial request at that level and not just linking the initial request to the highest level you actually need? Doing an initial request at the highest level is not very Agile. 

[Julien REBILLARD]

I will try to explain by example.

My client makes me a request, for example "Develop an online store" (PROJECT-123 key), which will contain the different elements transmitted by the client.
My Business Analyst will work on the request with the client, and the stories will come out grouped into Epic.
Example :

• Epic Authentication (PROJECT-124 key)
• Story 1: Login (PROJECT-125 key)
• Story 2: Register (PROJECT-126 key)
• Story X: Loprem (PROJECT-127 key)

My hierarchy would therefore be

• PROJECT-123
  • PROJECT-124
    • PROJECT-125
    • PROJECT-126
    • PROJECT-127
  • ...

So I can keep the history of actions/work and the initial request serves as a "bridge" between JSW and JSM for customer comments (synchronization of the 2 with element & copy app).

So you think I should cancel the initial request to only have Epics at the highest level, without keeping a higher link ?

[John Funk]

For your last question - yes. Still create PROJECT-123, but then link it to PROJECT-124. That way if there is no PROJECT-124 and just PROJECT-125, then your process is not any different and you don't create a "fake" Epic just to have a filler link. Just my thoughts.  :-)

[Julien REBILLARD]

So in the ticket hierarchy, this would give:

If I want to make an Epic's initial parent request, I manage it with a custom issue link.

[John Funk]

Yes, that's what I would do. But what are all of those issue types associated with the Epic? It should probably just be the Epic issue type. 

[Julien REBILLARD]

This allows me to have the new concept of parent - child in my stories. Like a Initiative, but with issue type Developpement, Evolution (issue type link with my JSM issue type).

So on my highest level issues (all types except story and subtasks) I have the "Add child" button displayed, and if I need to create a specific hierarchy between an epic and another type of level 1, I achieve it with a personalized issue link.

[Julien REBILLARD]

If I have an Agile division which does not necessarily require the creation of an Epic, in diagram 1 I am obliged to create an Epic to be able to attach a story to my initiative. Diagram 2 allows me to bypass the Epic while keeping the notion of Parent field, Diagram 2 correponds to all my issues types in the Epic level.