Epic Feature Story Hierarchy?

[Tej]

Hi,

Here Initiative Epic Feature Story Task is the Hierarchy want to achieve.

Portfolio take care of Initiative-Epic

The problem comes with Epic-Feature-Story, how to achieve?

With Structure plugin, I linked Epic Feature and Story but the problem is when I update story tickets there's no progress in Epic in the Agile Backlog Board, epic progress gets updated only when the feature is updated there's no relation between stories and epics now.

I don't think we can rename default Epic Issue Type and change it to Feature?

Dave

[Eugene Sokhransky _ALM Works_ · Accepted solution]

Hi Dave,

You can actually change the name of the Field that will work as an Epic on Agile boards to anything you want, including Feature.

The parameter that makes JIRA treat the type as Agile Epic is Description, which says: gh.issue.epic.desc

Here is an example of such setup:

https://structure-safe-jira.almworks.com/secure/StructureBoard.jspa?s=197&os_username=demo&os_password=demo

As for rollin-up progress, you should be able to see it in Structure. If something doesn't work, please let us know and we'll be happy to look into it. You can leave a comment here or open a ticket in our JIRA:

support.almworks.com

Thanks,

Eugene (ALM Works)

[Tej]

Thanks a lot for help.

good to know, about gh.issue.epic.desc

[Deni Christopherson]

Hi Dave,

I was curious if you ended up just using Portfolio and changed the name of Epic to achieve your desired hierarchy? Or if you ended up using Structure.  I was about to do a similar test using Portfolio and was just curious of your outcome.

Thanks,

Deni

[Eugene Sokhransky _ALM Works_]

Hi Dave, Deni,

A quick update on the Strucutre side - we've added support for Portfolio Parent links so you can now use two tools together (most customers would use Porfolio for planning and Strucutre to tracking and other everyday activities).

Here is a series of blog posts covering this use case. Maybe it will be useful for you:

http://almworks.com/blog/2017-01-track-portfolio-plans-real-time.html

Regards,

Eugene (ALM Works) 

[Zeke]

You must consider the agility of the story

[Davor Raic]

Hi Eugene, which credentials can I use to see your example in Jira?Best regards, Davor.

[Eugene Sokhransky _ALM Works_]

Hi Davor,

demo/demo should work. Please let me know!

Regards,

Eugene

[Shedyk]

Hi Eugine,
Link for changing epic description no longer works.

I get message Unavailable item

[Eugene Sokhransky _ALM Works_]

Hi Shedyk,

I'm not sure what could be the case there. Maybe something was changed in the later versions of Jira. 

What might be worth checking is this addon:

https://marketplace.atlassian.com/apps/1218959/safe-epic-to-feature-translator-for-jira?hosting=server&tab=overview

I haven't tried it myself yet, but it seems like a good far more complete solution for this scenario - it even translates the link type name and works for JQL queries too.

I hope this helps.

[Amarjit]

What? Jira is unable to create the following hierarchy out of the box?

• Epic
  • Feature
    • Story
      • Task (Deve, Test, etc)
      • Bug

So how do you view details for tracking purposes.  This is all out of the box functionality in Team Foundation Server.

If Jira does not allow this or does not understand that this is basic Agile/Scrum software development then its not fit for purpose.

[GabrielRoth]

That's a pretty myopic view. Adding additional layers isn't very "Agile", and Jira is built around those best practices. This hierarchy is entirely possible and not difficult, but why create the additional overhead?

[Bill Sheboy]

My perspective is that there are no best practices; only better ones.

Assuming the tools we use are the *only ways to solve problems* seems team-limiting to me.  I would rather use flexible tools which allow teams to start where they are, and gradually improve.  That includes when a team needs multiple levels/sizes of work items to manage their work...until they reach a point where all their work items are MVPe sized (minimum viable product experiments).

[JIM HODGEN]

Absolutely agree.  this seems to be part of the 'born on small teams and projects' heritage of Jira.   Once there are 15 to 20 stories and the attached  bugs, and sub-tasks, Epics start becoming too mushy and hard to navigate.  An additional layer of focus is very valuable... but can't seem to find a reliable way to do it in Jira.

I just keep getting some raw wood and am told to get a saw and start building because Jira is so flexible and customizable.  What makes me so frustrated about using Jira (compelled to do so at the moment) is I don't get paid to build tools, I get paid to create commercial features.   This is not a hobby for me it is a job and I get measured by output not cool things that don't create revenue.   Creating those scale tools is Jira's job.

Unfortunately, management is convinced that Jira does everything necessary... but doesn't like the massive wads of stories that accumulate as the project builds.

[rajanibs]

We created a new issuetype "Feature" and custom links, but managing/tracking these are very tiresome without plugins. Btw, plugins are too costly to go for....

[rajanibs]

I have started using Excel VBA Macro to pull in the information from JIRA and created reports in a format that is useful for us. Only issue is that it is not real time, but it is good for the time being and cost effective :) 

[alban.kit.partner]

I m so disappointed about JIRA : how is is possible that you can't organize by Epic>Feature>Story>Task ? It's not an amazing feature ...

So i have Feature>Story and I use a tag to identify an Epic 👎

[Alok Juneja]

Hi @Isaac Sacolick

i would appreciate if you please share your approach to create epic - feature - story hierarchy.

br,

alok

[Isaac Sacolick]

I'm also trying to get a hierarchy that looks like epic->feature->story. I want Epics to work as/is in Jira (ie, epics on the rails for navigation), but also ask POs to break epics down to features and then stories. I have some rationale behind this and can explain it to anyone interested.

Reading through these comments, I can see renaming the epic issue type to feature and then use Portfolio to create a new epic type that lives above feature. This isn't elegant because I lose the epic level navigation in Jira because it would be more granularly defined w/ Features. Also, I have to apply this to projects that are in progress, so it would take some work to realign the hierarchy.

Is there a better approach? I haven't tried the Structure plugin.

Thanks!

[Vlad Lessage]

Hi Isaac,

Thanks for posting.

How are your epics linked to features and features to stories?

Structure allows you to visualize issues based on a hierarchy you define. This is done using the Automation feature, via Generators, specifically the Extend Generator.

If you don't want to go down the recommended path of renaming the epic issue type, and you're willing to use an app, we can discuss your use case further so we can make a recommendation.

Our support team is always eager to help and can be reached at support@almworks.com.

Best Regards,

Vlad

ALM Works

[Chris Hansen]

I'm constantly amazed how Jira fails to address product management principles properly.

Being forced to programmatically customize Issue types into various themes is a LOT of overhead.

Being forced to buy add-in SaaS solutions (Structure, now ALMWORKS) to address the lack of hierarchy (and then to have to customize this add-in once again) is a giant PITA.

TFS/AzDO has this nailed, and it's OOTB. I put together the backlog and structure / heirarchy I wanted in AzDO in <30 mins. For JIRA, I'm still struggling with the instructions. It will likely take HOURS to resolve this.

Meanwhile, my SM, Dev and QA team are waiting for me to finish my work so that we can kickoff my product.

Not a fan.

[Isaac Sacolick]

Chris - Azdo definitely has the better solution by making it easy to implement Features as in Epics->Features->Stories. After that one benefit, I find Azdo a "good enough" solution only if working with few teams and simpler architectures. The reporting is only acceptable if you use PowerBI and even then it isn't great. It's also harder to create a healthy blend of where teams can self-organize versus where you want standards.

Happy to share with you how I implemented Features and to make Jira easier to work with for product managers. Just a handful of one-time setup steps. 

[Liam Rosewell]

I have the same request for this readily configurable hierarchical approach where I can drill down from Epic to Feature to Story. I have previously used the classic project type with an on prem Jira instance, and with Portfolio sitting atop.

Now I find myself in an environment where we are using cloud and where I am investigating using the Next Gen approach and roadmaps, whilst another colleague is evaluating Big Picture. 

Based on the thread above I am assuming there is no 'easy' configuration for me to get this hierarchy?

[Chris Hansen]

Unfortunately, no - there isn't an easy way to get this OOTB. Based upon my research, you have to heavily modify a specific issue type, and then create custom jQuery logic to support it.

There are better ALM solutions out there that support agile delivery and product development OOTB.

[Stine Søndergaard]

@Liam Rosewell would you share the findings from you and your colleague's research? 
I was looking into NextGen as well, but me initial research showed that it still lags a lot of core features ... The bonus is of course the roadmap, but I'm not sure that the overview of lower level details is as good as the roadmap for epics ... 

[Davin Stewart]

We're trying to do Epic->Feature->Story as well and are currently using a Structure based on a board to insert the Epics which is then extended by links to Feature and then Story.

There are several disadvantages to the way Structure treats this situation:

1. Structure forces you to choose to display Epics (without normal tickets) OR tickets (excluding epics) but won't allow you to have a complete list of everything.  Why in the world would it be designed this way?!?!  It should just have an option to "Display Epics as tickets".  Instead they've introduced all sorts of whacko functionality around this and it's causing us tons of headaches. 

2. If I create an agile board structure and display Epics then it will always exclude any tickets that don't have Epics already since there's no "No Epic" grouping.  This is extremely critical and invalidates the entire board structure for my product managers.

3. If I create an agile board structure, display Epics, and extend Features into it via linking then when I move a Story from under an Epic to under a Feature, it blanks out the Epic Link field.  This invalidates tons of planning in Jira and makes our Epics unreliable.  We're working on building in some automation to correct it after the fact but it's extra work for the system and doesn't make a lot of sense.

4. It's not obvious from the documentation or brochureware but Structure will not allow you to use Rank to re-sort Structures based on JQL queries.  Only structures based on boards allow this functionality.  This is very disappointing due to the issues I mentioned above.

Long story short, Structure has some fundamental problems that are causing us frustration as end users.  It's very close to working but there are some signficant design flaws.

[Philip Heijkoop _ALM Works_]

Hi Davin,

Sorry to hear you've run into some issues here. You're experiencing exactly this because your structure is tied to an Agile board in Jira. There are certain limitations to the way issues on a board behave that Structure doesn't circumvent (nor should it).

Since under the hood an Agile board is based off a JQL query, maybe it makes sense to build a new structure, based off that same query, and then when you run your grouping and extend rules you should be having a little more success.

As to moving items under features removing the epic link, that's expected behavior if you move an item (since by definition it removes it at the source). You can also copy an issue under a feature by holding down the ctrl or cmd key, then it will create the new link without breaking the 'old' one.

As for ranking a structure by rank, you can add an explicit rule to sort by rank to include it. Please read more about it here.

If you'd like, I'd love to set up a call to go over these frustrations and see if we can get some of them sorted out.

Best,

Phil Heijkoop
Lead Solutions Engineer
ALM Works

[JD Lobue]

Do any of these workarounds to having Epic/Feature/Story/Sub-task hierarchy allow for the Features to be shown in the backlog epics view side panel with all necessary parent/child hierarchy relationships working? I created a test project and don't believe I can create features under epics and have all my features show as an issue under the epic. It appears I can only add sub-tasks to epics. Not sure why you want sub-tasks under epics.

If I add feature type, will my side panel of epics allow me to change to Feature, and view those? Or if I change epic to feature will the side panel in the Epics view now be called Features? The reason a feature is valuable to have as a child under an epic is so that you can close out features, for a quarter for instance. We want to have an epic that is tied to the higher component which can reside at the epic level and close out those features that we committed/forecasted for a quarter. A lot of work for what seems basic portfolio management that Atlassian doesn't account for. Thanks

[Ahfaaz Hussain]

Hi JD,

Were you able to find something to help you solve for this problem. I am facing the same challenge and trying to create a Feature Issue Type that replicate the function of an Epic in Jira but is at a layer above or below the Epic.Thanks

[JD Lobue]

No. Atlassian does not provide a hierarchy other than top level and sub-level. Doh!

[Magnus Johnard]

I am also looking for a view showing this simple hierarchy since my pieces of work are that big and need the break down to be small enough in a sprint. How can you make that visisble in Structure or Portfolio?

It is a quite basic requirement. 

[Vlad Lessage]

Hi Magnus,

Thanks for your post. 

If you could share a bit more information about your specific hierarchy (Issue Types used, how many levels etc...), I'd be more than happy to make some recommendations.

But as an example, you could take advantage of Structure's Automation Feature to bring your Epics into a structure, using the Insert Generator. Once you do that, you could use the Extend Generator to visualize Stories under Epics, Linked Issues under Stories, and Sub-Tasks as needed. You could even Group your Issues by Sprint after that.

I wanted to briefly mention how Structure could help you visualize your Jira issues but I'll be more than happy to address your particular case in more detail if you'd like. I can be reached at vlad@almworks.com and our Support Team is always eager to help at support@almworks.com.

I look forward to hearing back from you.

Best Regards,

Vlad

[ALM Works]

[Magnus Johnard]

Hello, 

As a PO I just want to get a default view of the following SAFe tree structure. I want to be able to drill down in the tree structure down to task in one view so I quickly can overview what is planned and refined. 

Epic

• Feature
  • Story
    • Task (Dev, Test, etc)
    • Bug

[Vlad Lessage]

Hi Magnus,

There are a couple different ways to achieve this. I recommend using the Automation Feature to get to the desired results. For instance, you could start by Inserting your Epics into the structure:

1. Automation > + > Insert > JQL Query: Type = Epicor Type = Epic and Project = YourProject (in case you need to be more specific)
2. You would then bring in the Features under the Epics. For that, you'd use an Extender: Automation > + >Extend > Choose the right option - choose the appropriate option ("Stories under Epics" if Features are linked to Epics with Epic Links or "Linked Issues" if there's a particular Link Type used in Jira between the 2 Issue Types.
3. Show Stories under Features: Automation > + >Extend > Linked Issues - All available Link Types in Jira will be presented as options to choose from. You will also get a chance to set the Link Direction and Extend Levels (level 3 applies here to show Stories under Features)

Simply repeat step 3 to show Tasks and Bugs under Stories by choosing the appropriate Link Types. 

Note: Please always make sure you're focusing on the top level of your structure (the row with your structure's name will be highlighted in blue) to ensure that the Generators are being properly applied to the whole structure.

I hope this helps. Please let me know if you need further assistance. Our Support Team can also be reached through our Service Desk portal by emailing support@almworks.com.

Best Regards,

Vlad

[Luciana Di Matteo]

hi @Vlad[ALM Works], 

how can I achieve that using portfolio? (with that I mean Initiative, Epic, Feature, Story, task)  I'using a Cloud version of Jira so Structure is not available yet. Thanks in advance

Luciana 

[Vlad Lessage]

Hi Luciana,

I'm sorry I previously missed your comment. In case you're still looking for help, here are a couple articles that should be useful in helping you setup hierarchies with Portfolio:

https://confluence.atlassian.com/jiraportfoliocloud/how-to-create-a-new-hierarchy-level-in-portfolio-for-jira-941618926.html

https://confluence.atlassian.com/jiraportfoliocloud/configuring-initiatives-and-other-hierarchy-levels-828785179.html

In regards to Structure Cloud, a launch is planned for the spring of 2019. To that end, the first Early Access Program (EAP) release was on January 15th, 2019.  If you'd like, you may request access to Structure Cloud EAP releases via this page. 

Even better, if you're willing to share your feedback with us you may also ask to join the Structure Cloud EAP on that page.

Best Regards,

Vlad

ALM Works