We are using the AGILE methodology in which we create epics and stories.
Can we customize the issues to make epics as childrens of existing epics
and stories as childrens of stories?
The current hierarchy is
Epic--->is a parent of--->Story
What i additionally want is
Epic 1--> is a parent of -->Epic 2
Story1--> is a parent of---> Story 2
At this moment it’s not possible to put an Epic inside another Epic.
The Epic is the highest point in the hierarchy, so you can’t make a “sub-epic”.
On the other hand if you want to create a hierarchy you can create a sub-task of the Epic or Story by accessing the issue, clicking the "More" button and selecting “Create Sub-Task”.
I understand that Epic is a greenhopper's issue type. But what is the logic behind the impossibility of putting an epic inside another epic or even a story inside another story.
In this website it is understood that Epic is not a parent of a Story which sounds logical but why is that epic is not allowed to put inside another epic or even in the case of Story inside a story. what is the point which is illogical in these cases.?
The problem with using sub-tasks is that you can not move only a single sub-task into a sprint, you have to include the parent task. At the end of the day what most of us want is to have an N-tiered heirarchical project where each atomic unit of the project can be included within a sprint.
Agreed, this is my biggest problem right now with JIRA for planning. I want to group features under the umbrella of an epic for a release, but those items themselves are too big for an iteration so they need to be broken down (need to be epics themselves so they can parent stories). And as Noah says, I cannot drag sub-tasks in to sprints. This is most frustrating!
We have a need to track epics associated to a corporate initiative across a large number of teams. We would like to have a Parent Epic that our individual Team Epics link to. This allows are teams to maintain their autonomy while giving our sponsors and leadership team the overall view they need.
How can we do this?
actually this is not true. I have an epic which is in an epic. i do not know how we managed to get this done and are searching a way to get rid of it but it is definitely possible as seen in my screenshotBildschirmfoto 2016-11-07 um 15.58.36.png
so you see we have an epic inside an epic
JIRA doesn't support more advanced requirements management features required to scale agile projects such as this (Greenhopper used to do it until it was killed off by atlassian). However almworks JIRA Structure does this and does it really well. This product makes JIRA usable at scale and is now my main interface with it for managing backlogs - I rarely use the JIRA UI now.
It seems a little odd to think of epics as the top of a hierarchy in pretty much any mainstream agile school of thought. An epic is fundamentally a former story which was determined, during grooming, to be too big. After splitting it into several stories, the "epic" is just a point of reference, saying "these things all used to be one thing".
Following that, a scenario has been written about many times where, after splitting a story into more stories, one of those new stories–upon further estimation–is still too big for a sprint and needs to be split up more. But now what? What becomes the epic of those new stories? The epic from the first generation story that was split, or a new epic made from the second generation story that was split? If the former, do we lose all record that the latter ever happened? If the latter, do we lose all historical ties to the former?
If the value of epics is information, then any design that forces a loss of that information seems poor.
Epic is a agile concept, not a Greenhopper concept. You're having this issue because you're trying to shove a square peg into a round hole, so this isn't a matter of "advanced concepts" not being supported by Jira's scrumboard, but rather a complete conflation of development and management needs.
Epics are not a parent node of a hierarchy. There is no hierarchy and there shouldn't be. Remember, we write "issues" that are to be resolved. Issues -> Issue -> single thing that is being asked for. Creating or envisioning relationships between them should remain loose as building tightly coupled graphs like that result in garbage process in the same exact way that they produce garbage software. So stick to the concept of issues. You can use filters to see, find, group, report, etc., without connecting everything at the neck.
The epic is simply a group of related stories that result from a single story being determined as too big to be accomplished in a single iteration (or sprint if you're doing scrum). Within an epic, you can have themes that are logical groupings of related stories within an epic, but hey are not an issue type. We implement them as labels because not only is this not a hierarchy, but an issue for a theme doesn't really add any value to the development process. Any inter-dependent stories can be denoted using the "blocks" or "is blocked by" linking available on the platform.
Write a story. Have your devs look at it to determine if it's too big. If it's too big, split it into multiple stories that aren't too big. The original story becomes the epic and the resulting smaller stories become stories within the epic. Each story can have subtasks that are essentially just "TODO" items. Point estimates go on the story, hour estimates (if you use them) go on the subtasks. Those hours roll up into the story hour estimate. When all subtasks are done, the story is done. When all stories are done, then the epic is done. Wanna know which epics are part of a single initiative? Tag them and write/save a filter it so that you can find it later.
@Christi Heatherly use reporting gadgets. If you need to report on related epics and such, just tag them and/or the stories within the epic with a label that describes the logical grouping. You can then create a filter that sucks those all into any report of your choosing. Create a dashboard for it and place your gadget there.
@noah arliss If you're trying to move single subtasks into a sprint, then you have not written a proper user story. A user story describes a single deliverable that can be accomplished in a single iteration (or sprint). If it can't be delivered in a single iteration, then it's too big and needs to be broken down more. In many cases, it can be accomplished as "vertical slice" (a deliverable that accomplishes functionality from the UI all the way to the database and back) where each subtask is worked by someone different inside of the same sprint, making it possible to, for example, knock out a 13 point story in 2 days where 13 points would normally take a single person, the full 2 week sprint to accomplish.
I think it's important to remind yourselves that agile methodologies are about facilitating the development process, not the management process. If you continue to butcher these methodologies to serve your need to report to you're superiors, you're likely just over-complicating the process and slowing you and your developers down with unneeded encumbering process. JIRA provides a lot of tools that sit on top of the development process to aid in your ability to report (labels, filters, gadgets, reports, exporting, etc.), but those are concessions. This methodology is both opinionated and focused on what it was intended to be focused on, and that is developing good software that meets requirements. You'll have an easier time if you respect that and separate the concepts, choose the right tools (plural), and stop blaming JIRA for not sharing your flavor or idea of "Agile". Expecting them to do so would inevitably result in an overly complex and unusable platform.
Unfortunately that is a lovely Utopian view of pure Agile for a software house but doesn't fit the new project we are trying to set up or many development projects. At the end of the day, most developments are being done in house in a business environment and business is footing the IT bill so need a certain level of visibility and organisation
Our PO will be receiving requirements from both customers and from the scalable business platform for the application.
He needs to be able to group these into something like Epics (eg generation of a specific EDI interface). Usually in agile, adding stories under this epic would be enough, but in our case the pieces of work to be done need to be done by different development departments (application dev, integration dev, info broker. print management etc) and the level of information of what each of these departments must do is not as small as story level but isn't achievable in its own right,
Due to our organisation set-up we cannot guarantee that all the development departments will be working in sprints or happy to include the PO to the usual level required for agile, some of them work waterfall, some a type of agile but all work differently. Therefore the PO cannot work with them on the basis of them breaking the stories into managable stories in Jira and accepting them in sprints etc.
We had thought about just using (assigning ) stories even if they're too large. to the various work teams as their work packages but then that causes a problem for the development teams who DO want to work agile with Jira may need to break down these 'stories' to sprint size chunks if they choose to work in scrum. The PO doesn't want or need that specific level of development but the developers do.
Realistically we need a structure where we can have the following:
* Kanban visibility of Epics for the PO
* Kanban visibility of 'work packages' within those epics for the Development / IT services managers
* Kanban or Scrum visibility for specific work packages for the various development teams with ability to break these down into stories or tasks depending on how that team works,
I have seen 'Issue Type' added as a way of making stories different levels of story within Jira but this is actually less close to the Agile concept than using Epics in Epics would be to achieve similar for us
If you have a good solution I'd like to hear it but there's no point in ranting about people not staying pure agile. This i the real world.
That sounds a lot like the environment I operated in, in my last project. We evolved to the following conventions over time:
1. Epic was used as defined in scrum framework
2. Levels higher than Epic, e.g. Initiatives, were identified with Labels. (For awhile, we created a whole additional layer of Stories to represent Initiatives - i.e. we hacked the system - but this was abandoned as too much overhead)
2. User stories are included in an Epic, as per JIRA structure
3. If, after this, we wanted to split a User Story because we found during analysis or grooming that it was too big to be a single story (as per Scrum definition), then we created additional 'child' stories and refactored the original story to point to the children via Links and describe whatever relationship they may have with the parent or each other.
4. Similarly, if we had external dependancy (defined as outside the scope of our product, but necessary for the solution to work) we would create a 'tracking' user story and set up the necessary links to show which of our stories were dependent.
There was no expectation that all the stories in an epic would be implemented in a release. A release was the sum of stories completed in each sprint within the release.
JIRA has decent tools to create dashboards or widgets to count/group/show items based on labels as well as type, so the PCO could still have the kind of visibility they wanted. The only thing to note there is that this was historical info, not planning info. Hope this helps.
...word of mouth, so by 2016, we were working with several other entities on campus to implement Jira Service Desk . The Atlassian motto of “for every team” has really come true for us in this case. We...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot