How to move Epic in workflow?

[Nikola Velevski]

How to move Epic in workflow / do we need a separate workflow for Epics and to whom is the Epic assign to (Product Owner or Scrum Master)?

What means: 

• If you are moving an epic, you will need to move all issues within that epic separately.

[Tarun Sapra · Accepted solution]

Hello Nikola,

Your question is not concise enough.  Epic workflows is a combination of tooling and processes.

Epic generally have a different workflow then story. Epics are assigned to POs and they move the Epics based on the progress of stories by the various development teams. An epic can have easily upto 20 stories.

You can also automate part of Epic workflows based on workflow statuses of the child stories. Like closing epic once stories are closed etc.

As you have asked 

• If you are moving an epic, you will need to move all issues within that epic separately.

It's more of a process question not a tools one. Generally epics move after the child stories have moved in the workflow.

Like moving the stories to "done" can mean "Epic is in UAT phase" but moved stories to "Production live" might mean Epic is closed/Done/Deployed.

[Thomas Schlegel]

Hi Tarun,

since Nikola cites the original text from this page: 

https://confluence.atlassian.com/jirasoftwarecloud/moving-an-issue-902499026.html

I think he wants to move epic and issue to another project. 

[Tarun Sapra]

Indeed Thomas, this seems to be the case. Nikola, seems to wanting to move the Epic to another project. Though moving the Epic to another project doesn't move the child stories. 

[Nikola Velevski]

Hi from me, thanks for your replies. @Tarun Sapra @Thomas Schlegel @PM
I don't want to move the epics to another project.
My question is whether i need to have another workflow fro Epics?
I'm new JIRA Administrator and i don't have too much experience with JIRA. 
I have a project that uses one Workflow. I have stories and tasks related to epics, but in Active Board, i can only view and make transitions of stories and tasks. And when i do transition to done, the Epic is not in DONE status. How to solve that, i need solution from your experience. What to do with epics, and by default who needs to be the assignee of the Epic?

[Thomas Schlegel]

We use Epics as a container for a bigger topic. Epics are assigned to project lead and do not change their status as soon as this big topic is totally completed. 

Since the Epic is a regular Jira issue, you can close it. Therefore we have the closed status for epics. They are open or closed, nothing else.

If you close an epic, unfortunately it is not removed from your board. There you have to mark the epic additionally "as Done".

[Nikola Velevski]

Thank you @Thomas Schlegel,
but you said that you have separate workflow for Epics, can you describe me that solution please?

[Tarun Sapra]

Hello @Nikola

Here's how to conifgure different workflows for different issueTypes (called workflow schemes)

https://confluence.atlassian.com/adminjiraserver071/configuring-workflow-schemes-802592719.html

As far as the process is concerned I have already shared that in my answer.

[PM · Accepted solution]

Each issue type will have it's own worflow schema, you can use the same schema if you like. But each issue type needs to transition through the workflow on it own. 

In your example, stories linked to your epics will transition throught the workflow from backlog to work in progress to done. Where as epic will retain in backlog until you transit it via its own workflow. 

However, there are addons out there like 'JIRA Misc Workflow Extensions'. Which let you link workflow betweens issue types. E.g, moving the first task will automatically move the parent story. 

Hope this helps.

[Thomas Schlegel · Accepted solution]

Hi Nikola,

we have a seperate workflow for Epics. They have only two status:

• open 
• closed

Moving an epic... means, that, if you move an Epic to another project, all the issues connected to that epic remain in the old project. You have to move them seperately to the other project. This is different from moving an issue with subtasks.