You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Epic is a user story that due to its large size, the team breaks down into stories with a more suitable size to be managed with agile principles and techniques: estimation and close monitoring.
Stories are end-to-end and user-defined requirements that can be broken down into smaller tasks. Can lead to tasks that fall on different projects
But how do you go about managing all this structure in Jira?
For example, in my organization we have initiatives that are broken down into epics, which in turn are broken down into user stories and these in turn into tasks that can fall on different projects. In Jira, user stories as tasks and that can only be divided into subtasks IN THE SAME PROJECT.
How have you solved the problem without changing the functionality of the epics?
Hi, @Maite Rodriguez. Welcome to the community.
There are many threads on this topic here in the community. It really comes down to what will work best for you and your org.
For example, what do mean by "without changing the functionality of the epics." I bet if you asked 10 ppl what the essential parts of an Epic are in Jira, you'd get 8.5 different answers.
That said, here is a summary of what I think you will learn.
It's essential to decide whether or not you want to do things by the (Atlassian) book as best you can, doing things the way Jira is designed to work out-of-the-box, OR, if you prefer to think of Jira as a platform, that can be (relatively) easily be shaped and molded to things the way you'd like to do them.
Your questions suggest you are already leaning towards the latter, and there are a number of Atlassian Marketplace apps the can help you go down that path if you are sure that is the way you want to go.
But, as I said, "it depends." ;)
Indeed, many companies create custom hierarchies reflecting the specific needs of their business with the support of PPM tools.
You can use Issue Links to create hierarchies above and below Epics as well.
To visualize and track your hierarchy progress, you can try out our plugin Agile Tools.
The add-on allows you to visualize your Links hierarchy with option to view all your custom fields on a single screen.
Key features of Links Hierarchy:
You get multiple other features as below in the same app
There are some misconceptions in your thoughts that are quite common :)
First of all, a Jira project is nothing more than a classification of Data. It is not tied to Projects even if it is named that :)
Secondly, a Jira issue can only be created inside a Jira project, but it can live inside any board.
Thirdly, you are mixing business processes and development processes and you are focusing on projects instead of systems and teams.
I suggest you do this mental model:
These two things are NOT the same and they usually live in two different areas (Portfolio vs Jira project). Confluence is there to bridge the gap between the two and ensure the documentation is maintained bi-directionally.
An Epic is just a container. Nothing more, nothing less. It can be used differently in different Jira projects (a business need Jira setup will have it as strategic levels and a development Jira will have it as features).
In development, Jiras Epics are used as a rubber band to keep a feature together if it stretches over multiple iterations.
A story is not a User Story. User Stories are requirements, and Jira is not a requirement tool. A Story is a work order to develop one or more user stories. Or you have multiple Stories for one User Story.
Any attempt to have both the business process AND the development process in workflow is making life very hard on themselves. Not only will the workflow be extremely long, you also will have two sets of fields that will mean very little to the many people involved in all the processes.
You probably already have realized that there is not a 1-1 relation between ANY of the steps in the process, meaning that you will have to brute force and compromise in every step just to fit it into a single workflow.
So my suggestion is to start breaking things down into processes and areas of responsibility. Then create a business Jira for project and program management on Portfolio levels, and use Confluence in between to document things that flow from the business side to the development side.
Feel free to check my old presentation here for more information on how I tend to design Jira:
I am working on an update, but it will take a while :)
"Yes" and "no," @Maite Rodriguez. Using a Jira add-on app like Structure or BigPicture you can adapt your hierarchy any way you wish, and many companies do this (both products have over 10K active installations).
There is no way (that I know of) to make this kind of adaptation without using an Atlassian Marketplace app.
If you choose to evaluate Structure I can help you arrange a use case (your use case) demo if you'd like.
Thanks for the welcome :)
Indeed, the complexity of our organization has led us to use Jira as a base tool adapting it to the internal needs of the organization.
We are already using the advanced roadmaps of Jirato manage the hierarchy of issues. However, this hierarchy is not modifiable below the epic. Can we adapt it? Of course, yes, raising the hierarchy epic as a parent task and therefore losing its funcionality (epic link ..). But this has a high impact on an organization that has been running Jira for months...
Hi @Maite Rodriguez ,
we had the same issue, when we started using the Container functionality of Epics for project management. But after some time we needed this more and more and so we added this functionality to Epic Sum Up.
For Server and DC you c an use the function of beeing Container on any issue and create flexible hierarchies above and beyond Epics (and Roadmap Items). Looks like this:
The Cloud will have Containers soon..
Do you think of something like this?