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?
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:
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:
Eugene (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:
Eugene (ALM Works)
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:
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.
What? Jira is unable to create the following hierarchy out of the box?
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.
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).
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.
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 firstname.lastname@example.org and our Support Team is always eager to help at email@example.com.
I look forward to hearing back from you.
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 firstname.lastname@example.org.
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:
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.
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 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 email@example.com.
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.
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.
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?
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.
@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 ...
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.
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.
Lead Solutions Engineer
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events