Note that this page only applies if you are using the
Classic Boards (which are no longer being actively developed;
read more).
If you are using the new boards, please see
Creating an Epic instead.
In GreenHopper version 6.1.3 and later, you can migrate your Classic epics to the new boards. Please see Migrating Epics.
If your project administrator has set up epics for your project, you will be able to create epics and link them to child issues, such as stories. You can then view the epic and related issues via the GreenHopper Classic search.
To create an epic,
- Login to JIRA.
Select Agile > Classic in the top navigation bar. Then select Classic Planning Board from the drop-down below the project name.
- Select your project from the project dropdown in the top left of the Planning Board, if it is not already selected. The Planning Board will refresh with information for your project.
- Click the New Card button (at the right of the screen). Create a new card with the appropriate issue type, i.e. 'Epic', if your project administrator has set it up. See Creating an Issue in GreenHopper Classic for details.
- Save the new card. If your project is using the 'Scrum' template, the new card's issue key will automatically appear in its 'Epic' field. If not, edit the new card and type its issue key into the 'Epic' field.
To associate an issue with an epic,
- Login to JIRA.
Select Agile > Classic in the top navigation bar. Then select Classic Planning Board from the drop-down below the project name.
- Select your project from the project dropdown in the top left of the Planning Board, if it is not already selected. The Planning Board will refresh with information for your project.
- Locate the card you want to associate with your epic, and click the icon to the right of the 'Epic' field to edit it. (This icon will appear when your mouse pointer hovers over the Epic field).
- Enter the issue key for your epic in the 'Epic' field and click the 'tick' icon to save this change. Your issue will be associated with the epic.
To view all issues associated with an epic,
- Login to JIRA.
Select Agile > Classic in the top navigation bar. Then select Classic Planning Board from the drop-down below the project name.
- Select your project from the project dropdown in the top left of the Planning Board, if it is not already selected. The Planning Board will refresh with information for your project.
- You now have two options:
- On an epic card, click the epic's key at the bottom right of the card to see all the associated cards.
The words 'Show all linked issues' will appear when you hover over the epic's key. - On a non-epic card, click the associated epic key in the 'Epic/Theme' field of the card.
- The 'Epic/Theme' popup window will display, showing all cards associated with the epic. The card for the epic and statistics for all issues associated with the epic will be displayed on the right of the popup window.
Screenshot 1: Viewing all issues associated with an epic from an epic card
Screenshot 2: Viewing an epic and associated issues on the 'Epic/Theme' popup window
81 Comments
Monique Vael
I would like to break down epics into smaller epics and then create stories which can be done in a few days. Is it possible to create a whole tree of epics ending up with stories and tasks?
As far as I can see it is not possible to break stories in smaller stories and breakdown these smaller stories again, is it?
Please tell me what are the limits in breaking down epics and stories?
Nicholas Muldoon [Atlassian]
Hi Monique,
Within JIRA you get two real levels of hierarchy, parent (Story, for instance) and child (Task). In GreenHopper we add a third level of hierarchy, which we call an Epic or Theme. Beyond this you are limited in the level of hierarchy that you can have within JIRA and GreenHopper.
Please note that due to GHS-2136 we do not use a parent, child, grandchild relationship in GreenHopper. Instead we rely on the JIRA Labels plugin to provide the Epic/Theme via labels.
Thanks Monique.
Regards,
Nicholas Muldoon
Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com
Monique Vael
Hi Nicholas,
Thank you for your reply.
regards,
Monique
Pepe
So an epic primarily gives a 3rd level of structure. A feature that comes up often is that an epic should remain unresolved until all of its user stories (plus other issuetypes and related sub-tasks) are resolved. If that logic were to be implemented it probably belongs in the jira-core instead of greenhopper but I was just wondering if there was a reason that that is not the case. I've often wonder the same about issues with sub-tasks.
Hans
Agree that this is one of the roll-up type behaviors that I'd expect. I suspect that you might want a switch as to whether this was automatically so.
Others roll-up behaviors would be:
Anonymous
Jira/Greenhopper is really limited. For that reason we are now using Rally, which is more flexible and scalable and can describe a deep hierarchy of stories if needed. Naturally, if you need to go too deep you should start thinking about whether you are describing the backlog in the right way.
Nicholas Muldoon [Atlassian]
Hello,
Sorry to hear that you feel JIRA and GreenHopper is limited. If you would care to share the weaknesses of our products that would be great - we are always looking for feedback to make them better.
Thank you.
Regards,
Nicholas Muldoon
Anonymous
I'd like to voice my main issue with GreenHopper and Jira. Jira doesn't allow users to add Stories as a Sub-Task to Epics, which is how Scrum actually works. We should be able to create Epic > Story > Task, as a subtask of the relevant issue.
This is a big issue for me, as we've just trained 30 people on Jira, and the main workflow issue is, 'we can't add stories the logical way'.
This simple fix, would change our workflow a huge deal.
Anonymous
Yes, I second this. It seems counter intuitive that you cannot associate stories with epics-- looks like you need to use tasks. So what happens when you want to elaborate the substories? You move them out and change them over to tasks?
Anonymous
I think the weakness of the product is pointed out in this thread pretty clearly: there isn't much hierarchy. Two real levels is what you say, plus a third fake level created with labels. In the real world, it's hard for me to believe that only two levels are needed. The product should have multiple levels of hierarchy. I think the problem is that this is an issue tracking system trying to be forced into a project tracking system. Projects typically need more than two levels of hierarchy. Look at Microsoft Project or any other real project tracking tool.
He who has ears, let him listen
Pitty
Hi Monique,
You can create a tree of issues with Structure JIRA plugin. I actually use this plugin to view all my epics (and his stories and sub stories) in a tree format.
Anonymous
I'd agree with Pitty, we are using Structure to great effect to give us both a high level view of all the Epics in the project, and also provide multiple levels of hierarchies to give better definition to the stories.
Mohnish Thallavajhula
Is it possible to set up the Structure plugin's reporting to use story points in place of time tracking or issue tracking? E.g. if I have 3 stories in the structure whose points are 3, 3 and 20 and I've complete the 20-point story, I would expect the percentage bar to reflect a weighted calculation (e.g. 77% over 33%).
lili
Faible quantité de rayonnement, les patients et le personnel des garanties exagère de l'exposition aux rayonnements, appelé "Green" machine à rayons Xhttp://www.dentaleshop.fr/
Pas de gardes spéciales sont nécessaires pour le médecin et le patient, pas besoin de chambre noire soit
Anonymous
I'm a new Greenhopper user and I have a couple of questions. First, why do you recommend using Epics for lower priority stories? And second, I am having a hard time creating a list view that sorts all stories for a particular component by Epic so that I see an Epic followed by all its related stories (instead of having to go to the card view). I've tried sorting by both label and Epic/Theme without getting the list order i want.
Nicholas Muldoon [Atlassian]
Hi,
Epics are really just used to group a collection of similar stories. Depending on the circumstances you may find that an epic spans many sprints, and as stories are added to a sprint their priority is necessarily raised.
When sorting the planning board by epics you will want to configure your current context (or create a new context) that is sorted by Epic/Theme. This will display all epics with the stories/tasks/etc associated with that epic below it.
Thank you.
Regards,
Nicholas
Anonymous
Epic/Theme is a text field so it doesn't perform sorting and grouping properly!
It only works if you don't create more than 10 items and you create them in order.
Anonymous
Hi Nicholas -
Can you describe how to create a context that will display epics and associated user stories together?
Thanks - Ton
Anonymous
Can you please explain exactly how to configur my context so it it sorted by Epic/Theme?
Anonymous
Click on the small down arrow on the Context name (right to your Project's name in the header). then select Manage in the drop down.
Then Select sorting.
HOWEVER: IT is only possible to sort on Epic/Theme ONLY, what you want is probably Rank AND EpicTheme if you are in a Planningboard view.
Loosing the rank sorting makes the view quite unusable if you're using Epics
Ian Kent
In the instructions and screenshots on this page you use "Epic" and "Epic/Theme" for the custom field name. In instructions for [Setting Up Epics for your Project] section in GH Admin Guide you use only "Epic" as field name. When epic support was first implemented in GH 4.1 we created a custom field named "Epic" as the GH Admin Guide recommended. Since later upgrades to GH (we are now using 5.0) we see a new custom field named "Epic/Theme". We are now confused by the two custom fields; "Epic" and "Epic/Theme". This is very confusing.
Anonymous
I've noticed the same thing about ranking field, suddenly there are two of them after the gh upgrade. Is that really necessary?
Heikko
Anonymous
Hey, as stated about the popup of Epic/Thema, that we will see the Epic and Summary on the right side of the popup, and issues related to this Epic on the left, but on my GH5.3, I see only on the summary on the right, and on the left, Epic, Story and Tasks are mixed up. Could you please check if which version you could have this nice grouping?
Also, the tooltip when moving the mouse over the Epic field is: Show Issues labelled by "EpicName", and not "Show all linked issues" as you have here.
Thanks for this nice work!
Anonymous
Hi,
BOX-6 (The Epic) shows at right corner a sum of the 3h 31m.
But, the sum of time spent by BOX-13 + BOX-14 + BOX-15 is 10h 32m.
What is wrong? Why this difference?
Anonymous
This example shows right corner field configured for epics to show linked issues. Yet, I did not find in User/Admin guides how this can be configured. By default, it is not shown of course and neither I found any suitable field to assign through Configuration. Any suggestions? Thank you!
Evert Penninckx
I'm in the same situation. Configured according to the doc. Yet I can't see how to get the issue key link ("show all related issues") in the corner box of the card.
Anonymous
I'm having the same problem. I would really love to view all linked issues form an Epic's Card.
Anonymous
I'm using the Scrum template in my project. If you are using it, try configuring your project settings to show the lower right hand corner for epics (Card view). To do this, select Planning Board from the Agile menu, then select Configure from the Tools dropdown in the upper right hand corner. Select the Card Styles tab. Select the Issue Type of Epic. In the Card View section change "None" (in the lower right hand corner of the card) to "Epic/Theme" and apply the changes. Now the Epic Cards have the box and you can click on it to get a summary of all the Stories in the Epic. This only worked for me if I'd created the Stories from the Card view OR editted the Epic/Theme of the Story from the Card view, so that it referenced the appropriate Epic. Seeing all the stories associated with an epic worked perfectly in that case.
Andrew Webster
Is there a way to raise a story from an Epic by using the drop-down "Create sub-task".
I understand that Epics operate as a story label (which is real clunky btw). However, when I'm doing an epic decomposition into deliverable stories, I want to be able to do it with the least interruption and thought.
Greenhopper "trains" me to think in terms of decomposition from Story to Technical Task by using the drop-down. I preach consistency to my guys when they're designing a UI, so it sucks to have them go "Oh, but your precious Greenhopper isn't consistent! Nyah!" Not least as they have a point!
Anonymous
Wouldn't be easier to add story on the same way as you created epic?
- story could be part of an epic (one or more)
- tasks could be part of story (one or more), eventualy tasks could be part of an epic, but i don't think this would be necesarry
ghUser
I'm not sure what is exactly your idea of working with issus: scrum + greenhooper.
Could you give me some hint?
------------------------------------------------------
Let say that i'm working on 2.0 application version. I would like to have product backlog (for whole 2.0 version) & let's say Sprint Backlog for 2.0.1 version. My understanding was that i wil have to :
1) create 2.0-backlog as new version with all epics
2) epics should be divided into stories (as far as i know this can't be easilly done with greenhopper?) in 2.0-backlog.
Let's say that we can treat epics like stories, so there wan't be stories in 2.0-backlog - only epics.
3) We divide epics into tasks (no stories as mention before) in 2.0-backlog.
4) We create new version 2.0.1 (Sprint Backlog) with parent set to version 2.0-backlog (Product Backlog).
5) We should use Planning Board to plan the next sprint & move needed tasks to 2.0.1 version.
6) If sth i not done @ the end of the sprint - it should be moved to another sprint.
This should work fine for most cases, but i'm not sure if this is the right way - what do you think?
------------------------------------------------------
Secondly, let say that we have few stories that can be resolved be introducing new feature in application. This feature is complicated so the normal asumption for me would be - create tassk that have sub-tasks. But how can we deal with moving not finished sub-tasks to the next sprint? If we can finish 3 subtasks from 4 & we would like to release this version (2.0.1 for example). Should We close those issues in released 2.0.1 version but move parent issue with unresolved child to the next Sprint (2.0.2)? SHould it be parent-child relation? Or maby tehre is some other feature that allows sth like this? Or maybe i misunderstood sth & there is some other nice way to do it ?
Marco Wlotzka
I am missing the feature to easily move an EPIC with its related user stories to another iteration. Yes, I see them when clicking on the epic label. f.e.g. why not mark the related ones, when choosing the epic card, so that I can easily drag-n-drop them?
Any ideas?
Aren Cambre
This documentation appears to be about a prior or custom-configured instance of JIRA and GH. I filed bug report http://jira.atlassian.com/browse/GHS-2833 ("Working with Epics" documentation is incorrect) about this.
Also, why can't we make these relationships via the issue editing UI? Filed improvement request http://jira.atlassian.com/browse/GHS-2834 (Users can associate user stories with epics, and see these relationships, through the issue editing interface.).
Anonymous
We have an agile consultant in. When I said that there are only really two levels of hierarchy, he said "you need to get a new tool".
He says you should be able to have epics, themes, stories (with any number of child stories) and then tasks.
I have managed to link epics to other epics, but there is no way to visualised this hierarchy which would be really useful. Currently is it quite confusing.
Anonymous
I disagree. I believe are really only Stories and Tasks. Anything higher is just grouping and categorisation for release management. Having lots of hierarchy does not always make things better, but does always make it more complicated.
Anonymous
I have to whole heartedly dissagree here. If you've only been working with Stories and Tasks, you've been working on very small projects. Any project with multiple major features, being built by different groups needs Epics..and I'd argue even Themes.
At the moment, it doesn`t look like you can get past level 2. Without this level of organization, it's virtually impossible to track the overall state of large features. I should be able to click on an Epic on the planning board and see all the estimates and work logged information for all its Child Stories and all their Child Tasks.
If I can't do that, JIRA's simply broken.
Mark Everest
I installed the issue hierarchy plugin that shows a nice treeview of an issue and it's descendants, but it would be great if when linking issues the epic/theme fields could be automatically setup and vice-versa - this would stop us having to do the same thing twice (i.e. populate the epic field of a story with its parent item and create an issue link in the jira screen).
Anonymous
I'm transitioning from mingle, where I defined a hierarchy that went:
Epic -> Feature -> Story ->Subtask
That worked well for creating a rather complex system with subsystems. We're moving to Jira because of the integration with Confluence, but fear of hierarchy seems built-in. I see the hierarchy above as a natural way of elaborating the initially high-level conceptions of major functionality into developable stories. The stories are then restricted to at most a few ui screens (or a single wizard) implementing a very specific user goal.
Anonymous
We have tried to use Epics as third hierarchy but it doesn't really work for us in a big project.
It's fine for first iteration of stories. They will be written from design team and are all well designed. But when it comes to production, polishes and bugs pop up that are related to some part of the epic. This is done by anybody in the team and they don't know the ID of the epic. We tried with human readable epics but this doesn't work either because resolved epics won't stop showing up in the autocomplete list.
Before trying the epics we already tried lots of other workarounds. For our team the missing third level of structure is the biggest single flaw in Jira.
Anonymous
Hi,
it is strange to referring an Epic with its key instead of name on the card view. I there any possibility to fill the combo with epic names instead of keys?
Hans
Agree this is an issue. It means we have to keep a printout of a list of epics around so we can fill in information correctly. Just clunky.
Matt Sokoloff
Agree...it's odd for an "Epic" to just see the Key and not the name. Is there a way to change this?
Bret Kelly
As far as I have seen... no. The only less painful way is still somewhat manual but less so. I made a saved query that I then export daily (all fields to excel format). From there, I can use some excel magic from another sheet to do a match/vlookup of Epic ID and match that to the title. It's a bit hackish but it works.
davfive
I've created a Greasemonkey (free) script that can be used to show the Epic names instead of numbers. You can find it here:
http://userscripts.org/scripts/show/137114
If you are not familiar with Greasemonkey, you can learn about getting it working in your favorite browser easily at
http://www.pcworld.com/article/184108/use_greasemonkey_scripts_in_ie_chrome_and_safari.html
(if you use firefox, it's just an add-on)
Enjoy,
David
Shawn Wallack
We just installed GreenHopper and I'm trying to determine the best way to organize our work.
We have a single development team (10 people) working on multiple simultaneous business "projects." A project is comprised of requirements and use cases. For example, we might have one project to create a new widget and another project to fix a production defect.
Right now, we create a separate JIRA project for each business project. For example: "New Widget 2011" and "Fix Defect #13." Then within each JIRA project, we create issues (which represent the requirements of the project) and decompose those issues into sub-tasks (which represent the development tasks needed to produce the required deliverables).
Using GH, we can look at a single project (e.g., New Widget 2011) and prioritize its tasks by dragging & dropping cards. This makes it easy for a developer to know when to work on Task A and when to work on Task B within the context of that project
However, what we really need is a way to prioritize work ACROSS projects, so that our developers know when to work on New Widget tasks and when to work on Fix Defect tasks.
How can we accomplish this?
I'd also like to know whether and how we can use JIRA or GH to allow developers to see their work (i.e., their cards/tasks) from multiple projects in a single view. From what I can tell, GH displays everything in the context of a single project. We need to show prioritized work across projects.
Thanks.
Hans
I thinks we had a similar problem, but we took a different approach. We use "projects" for releases (we have multiple teams per product release). We then configured up a "Investment Allocation" field for each story and put in information about the business initiative that we are supporting. Prioritization works across the whole release then.
Not sure if this helps.
Anonymous
HELP!
I have installed jira 4.4.1 and greehopper, when I create stories and epics. I cannot associate the story to an epic. When I follow the tutorial above, the "Epic fiel" does not appear in the card. Any idea????
Nicholas Muldoon [Atlassian]
Can you please check that your project is using the Scrum template, found under Tools -> Configuration from the Planning Board.
Anonymous
In views, you should select Cards, otherwise only the Summaries will appear.
Juliana
Anonymous
I just need a simple view that shows nested stories under their parent Epic. This would be so helpful in trying to determine how much of an Epic is complete. I am finding the Epic/Story implementation in Greenhopper is useless, and it's making it doubly difficult to get my product owner's buy-in when I cannot even offer this simple view.
Anonymous
Adding my voice to the Choir. I want Epics to parent Issues not just be a glorified label search.
Nicholas Muldoon [Atlassian]
Hello,
Thanks for adding your voice to the choir. Please also add your thoughts on GHS-2136 and vote for that issue.
Thank you.
Regards,
Nicholas Muldoon
Bret Kelly
In the interest of saving some users of Jira/Greenhopper some pain, I have highlighted a few important points because this documentation SUCKS!!!
I STRONGLY suggest Atlassian updates this very poor and very incomplete documentation. So, here is what I learned after banging my head on the desk for a while...
1) Epics are not parents of stories. Period. They are helpful but do not think of them as a parent of a story. It just doesn't work that way so don't look for anything like that.
2) You create an Epic just like you create a story. But, this whole Epic thing is really a Greenhopper/Agile part, not part of Jira. So, I suggest going to Agile->Planning Board->Create Card instead of going via Jira to create it because Jira is just going to confuse you on this topic.
3) Okay, I have created my Epci but how do I tie together the story and Epic??? Well, this is the part that could use some work since it is really limited on where an how you can do that. But, here are your options:
- First off, make sure you have your project configured for this or you are dead in the water: Go to "Planning Board" within the Agile section of Jira. Click on Tool->Configuration on the right hand side of the screen (must be admin of project). From there, you need to change your project to the Scrum project template if it is not already.
- Go back to the Planning Board and change your view to the "Cards" view because the Summary view does not display the Epic for you to edit. Now that you can see this field, you can relatively easily edit it on existing stories.
- Use "Create card" from the Planning Board and you will be able to specify the Epic's ID from the card creation screen.
- It is probably my config but there appears to be no way to edit the Epic using Jira so I am only able to edit using the Agile interface (i.e., Greenhopper)
4) But wait... now I can put the epic on any card and it doesn't seem to inherit that to child cards??? Shouldn't it only allow me to add that to a story and then all tasks of the story also are part of the Epic?
Well, you'd think so but that is just not how it works. Epics must be applied manually to all stories and tasks that you want related to it. So, you either need to choose to apply the association to every task or just put it on the parent story and know that you need to drill down to get to the tasks.
5) If you want to see what is going on with your Epics, always use Greenhopper/Agile view, not Jira. Jira doesn't appear to display the epic information so you can't really use Jira effectively to sort out what is going on. Maybe this is part of my config but...
Hope this helps a few people...
Anonymous
Brent, good observations. I have been working this today and find Epics are lacking in usability. At least you should be able to update the related Epic anywhere you create stories. At when listing the Epics available, how about they provide the description as well so I do not have to remember the issue number. At least that would help!
Nicholas Muldoon [Atlassian]
Bret are you keen to provide some feedback on some changes to Epics?
If so please email me at nmuldoon@atlassian.com.
Thanks,
Nicholas Muldoon
Anonymous
> 5) If you want to see what is going on with your Epics, always use Greenhopper/Agile view, not Jira. Jira doesn't appear to display the epic information so you can't really use Jira effectively to sort out what is going on. Maybe this is part of my config but...
You can actually display the Epic/Theme field when workinf with issues in Jira by adding it to the default screen: Administration --> Issues --> Fields --> Custom Fields --> Epic/Theme --> Screens --> Check the "Default screen". The Epic/Theme field will now appear when you edit any issue in Jira, not just on the Greenhopper agile board.
Anonymous
Bret,
I spent hours upon hours reviewing the "documentation" on Epic/Story/Issue linking before stumbling on this thread. Thanks for this walkthrough it has been very helpful.
-Eli
Lilly Auburger
I want to import a huge lot of hirachical organized Epics/User Storys to Jira through csv file. How can I automatically create the label for stories, linked to a specific epic. Similar to the Issue ID and Parent ID construct for tasks?
Anonymous
Hi.
Same issues here, Epic/Story relationship in Jira/Greenhopper is not intuitive and definitely impossible to use efficiently with large team.
I have also legacy backlogs to be imported using csv import, but the whole epic-story mapping thing is missing. And there is no way to do this manually for thousands of stories and tasks.
Please post back to this forum if you get answers. Feels like it should be a minor update to fix these as Atlassian is growing, a lot.
Br,
a finnish user
Ilya Blokh
Just want to echo all the comments already here about making Epics parents of Stories, not just labels. Further, I would really like to be able to create custom hierarchies with any number of levels (not just Issue and Sub-Task).
Anonymous
Please read definitions:
http://agile101.net/2009/08/10/the-difference-between-agile-themes-epics-and-user-stories/
My issue is that I want to differentiate between Epic and Themes. I have decided to use Epic type and is GH functionality for Epics and a custom lable for themes but I am not sure if there is a better way. Anyone?
Anonymous
Is there a way to filter 'Resolved' issues when viewing an epic and associated issues? Viewing all the issues, resolved and open, is in many cases not very useful and makes the whole thing unreadable.
Zhenya Warshavsky
Completely agreed. Epics are floaters and do not graphically appear above the user stories that they are linked to on the planning board. Seriously a problem.
Anonymous
Why are epics counted as 20 points?
Anonymous
Does anyone what statuses can be created for "Epic" and "Story" issue types? Typically a status can be "Opened", "Closed" , "In progress", but i can imagine that there are more such intermediary statuses. Can anyone give me a complete list of available statuses for "Epic" and "Story" issue types?
Bret Kelly
It totally depends on how you or an admin has setup Jira. Go to Administration->Issues->Workflows->Workflow Schema to see what workflow is configured. If you have the defaults, it is probably just Open, In Progress, Resolved, Reopened, Closed.
Borek Bernard
Can Epics be used with Kanban projects? The issue type is there but I didn't find a way to associate a Store with an Epic on the rapid board.
BTW, I've tried to add the Epic/Theme field to the default screen as someone hinted here in the comments but when I then go to edit the issue, what should I put into this field? Auto-suggest doesn't suggest anything, should it be the issue id?
Shaun Clowes
Hi Borek,
At the moment there is no way to use Epics on the Rapid Board for Kanban, we will address this limitation in the future. For now you might want to try using a label and quick filters?
Thanks,
Shaun
Borek Bernard
Thanks, I think this information should be added to the page text to avoid confusion.
Rosie Jameson [Atlassian]
Thanks for the suggestion — done.
Anonymous
Working with Large teams I am perplexed as to why I can't have Multiple Stories under an Epic and shown as an indent in List view as a task does for a Story. This need sorting.
Anonymous
Confirmed! The lack of this feature drives me up the wall! Why it was missed I cannot understand. Please please please implement it.
Mark Haller
Agree with the comments above - we've burnt hours .... no actually days here trying to work out why the relationship of Project -> Epics -> Stories -> Technical Tasks doesn't work ... thinking all the time we're using the tool wrong.
I'm glad so many people are frustrated by this poor delivery and hope this is sorted in the next release of Greenhopper. Until then, we're going to have to go "old school" and drop the whole concept of Epics (no summation, no drill-down/indents, no ability to describe and share the project with the client) and prefix groups of stories with the epic name infront of it!
Please update this screen, Atlassian, if this is being addressed or you'd like more feedback.
JP Patrikainen
Could it be done like this with changing linking feature?
So, do you see the light in this idea?
Anonymous
I voted, you should too:
https://jira.atlassian.com/browse/GHS-2136
Anonymous
I voted, you should too:
https://jira.atlassian.com/browse/GHS-2136
Anonymous
Hello,
How do you deal with Epics within the task board. If we do not assign any time or story points to them, just the user stories below them, then do we put them into the sprints, then move them into the following sprint when more of the user stories are worked on? And does this effect the reporting?
Andy
Rolando Peñate
Is it possible to configure the Epic/Theme dropdown to show the ticket name? Currently ours is only showing the ticket number and that makes it a bit difficult to decipher which is which. Thanks!
Anonymous
Hey,
Is it posible to see all user stories when you open an epic? For example; when i open a user story, I can see all the sub-tasks. I would like to have the same functionallity when I open a epic.
Greetings
Alex Kempkens
Hi all,
Hi Nicholas,
Using GreenHopper is cool and there are a lot of tricks implemented you definitely do not find in the documents atm. Having some updates will help.
To overcome the issue regarding using labels or a more structured hierarchy ( GHS-2136 - Getting issue details... STATUS ) between an epic and stories it would be helpful to have an automated list similar as the links just based on specific labels. Within confluence it is easy to search all pages of a certain label. Exactly the same I would love to do in JIRA as well. Adding a list in the screen that shows all issues of a specific (flexible) label such as the own "epic" field. This way it is possible to show the related user stories not only via the popup screens but also while looking at a normal view.
KR
Alex
Anonymous
This is very frustrated... does anyone got a workaround for structure hierarchy issue?