Use of epics and other groupings in jira

[Maite Rodriguez]

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?

 Regards!

[Dave Rosenlund _Trundl_]

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. 

Typically, (Advanced) Roadmaps from Atlassian, my company's product, Structure for Jira, and BigPicture are on most people's top three list.

But, as I said, "it depends."  ;) 

[Anna-BigPicture]

Hi @Maite Rodriguez

Indeed, many companies create custom hierarchies reflecting the specific needs of their business with the support of PPM tools.

As @Dave Rosenlund _Trundl_ mentioned,  with BigPicture or Structure, you will be able to create a fully adjusted, multi-level hierarchy. 

If you consider BigPicture (my company product) features useful, I will be more than happy to answer further questions. 

[Rahul_RVS]

Hi @Maite Rodriguez 

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.

Agile Tools - Epic Tree, Links Tree and Time in Status 

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:

• Links Hierarchy upto 10 levels deep
• Progress % on "remaining estimate" or "original estimates"
• Edit Issue summary, time estimates, story points and assignee on the tree with real time updates in the progress
• Rolled up percentage completion at all levels
• Ability to add/remove the columns on the report

You get multiple other features as below in the same app

• More than 8 types of Time in Status Reports. Excel Export available for all status reports.
• Epic Hierarchy / Sum Up (Standard Jira Hierarchy Epic -> Story -> SubTask)
• Portfolio/Advanced roadmaps Hierarchy
• Worklogs Report
• Timesheet Entry screen
• Dashboard gadgets for all the reports

[Jimi Wikman]

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:

• A business need is not a requirement, it is a need. It is high level with high-level estimates and high-level design. Its purpose is to plan and act as a catalyst for financing.
• A Requirement is a need that has been broken down on a system level from the Business need. It is detailed with a detailed estimate and a detailed design ready to be developed or configured.

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:
https://www.youtube.com/watch?v=VGSccqGmoys

I am working on an update, but it will take a while :)

[Dave Rosenlund _Trundl_]

"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.

Cheers,

-dave 

[Maite Rodriguez]

Hi @Dave Rosenlund _Trundl_ 

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...

Regards!

[Andreas Haaken (APTIS)]

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?