First we briefly explain the terms.

Epic

The Agile view

Epic in agile methods is a group of user stories. What does this mean in practice? In agile work, stories are created that describe use cases. Usually, many stories have something in common and epics serve to group these stories together. So an epic is a “bowl” in which there is candy of one kind, maybe chocolate, while in a second bowl there are fruit candies, but both are part of the “Sweets” project. .

This can be called bottom up, because the stories are created and then grouped into larger units (epics).  However, the reverse top down principle works In many projects: first, the project is split into large epics, the functionality of a product might be one, and then each epic is split further into smaller stories, individual parts of a particular functionality.

The JIRA view

As mentioned, an epic is a fairly abstract unit. In Jira we have two abstract units (no life cycle) – components and releases (versions). The introduction of a third abstract unit would probably have been counterproductive, so the epic was “invented” as an issue type, ie it has its workflow, screens, and all the related features. In addition, special fields and rules were defined: Epic Name, Epic Link, Epic Status, Epic Color  (in addition to the Summary, how many times must we fill in Epic Name?), enabling agile to work.  There is only one problem type in the system “Epic “. Although it is possible to rename it, if the issue is opened, we see “Issues in Epic” even though the epic is renamed*. We also can not create other “Epic” issue types, only standard tasks or sub-tasks.**

_{**This is the built-in functionality, there are apps that can change this.}

_{** Administrators know of these limits} 

Scrum board and Sprints

Agile work is done by small teams call scrums, and done in time periods called sprints. In Jira, the work is shown on scrum boards where stories are created (and other types of tasks), assigned to epics and releases, and planned for completion in a short-term sprint. Sprints are most frequently two weeks long and all stories are to be worked on and closed in some sprint – each story should be a small enough piece of work to be completed in a single sprint.  If too big, it should be broken into smaller stories.  All the stories together make up the Backlog of the project.

This is a simple scrum board, showing the Epics, the next Sprint, and the stories in that sprint plus the remaining stories that are the backlog:

This example board shows two Epics (One and Two), a Sprint 1 with a Story 1, and a Backlog of other Stories (2, 3, 4) not yet in a Sprint.  Story 2 is in Epic One, 3 & 4 are in Epic Two.

On this BSP scrum board, Na scrum boarde sme naplánovali všetky stories patriace k určitému epicu. Tieto stories boli v sprintoch vyriešené. To znamená, že ten konkrétny epic už ďalej nepotrebujem pri plánovaní, potrebujem ho teda “odstrániť” z boardu. Tu sa môžu stať dva prípady.

On the left side under EPICS is the completion status of those story issues related to a particular epic. It’s expected that Story 1 will be solved in Sprint 1; possibly also Story 2 or some other Story in the Backlog, altho this should normally happen only when the planned work is complete or when is some external stop to progress on one story, allowing work on the next story.

After all the stories in an epic are completed, that epic is not needed on the board, it can be removed. The project will be done when all the epics are done.

Here are two ways to remove an epic.

Case 1:

Use the built-in functionality on the board and close the epic, “Mark as Done”.

Epic One, now marked as done, disappears from the board, based on the usual filter of only seeing incomplete Epics.

Yet the epic is not marked as done when I open it, because there is another status!

Case 2: Open the epic and then change the status to “Done”.

Here we can see some Jira behavior of an epic that may seem illogical to us.  “But I’ve closed the epic!”

Why is it like that?

The secret is that the workflow status of the epic does not determine whether or not an epic is on a scrum board. The “Epic Status” field, which is a selection field, also contains a few other possible values: To Do, In Progress, or Done. In case no. 1 when “Mark as done” is set, JIRA changes this field to “Done” and the epic disappears from the board. It does not change its workflow status. In case of No.2, we manually change the workflow “Status”, setting the value to “Done”. Which also sets the Resolution field to Done so it therefore has no reason to appear on the board.

What is recommended?

1: The “Epic Status” field is not normally on epic screens. So add this field to the screens. Then navigate through the Edit Mode for it to be or not be on board. Be careful, there is some risk that someone can change the value of the field, although it is not necessary. Still, you can always “go back” back through Edit.

or

2: :If you are an administrator, put on the post-function transitions to determine the value of the Epic Status field, or ask the administrator to do so and explain why you need it. Workflow status will always match the value in the “Epic Status” field. But do not make it create or edit the screen.

Conclusion

There is another scenario: the behavior of the epic suits you and you do not need to change anything. It’s also absolutely fine.  . This article is intended to introduce epic use explain some epic – board behavior and what can be changed by the user. If your experience leads you to have some other advice, we welcome your comments.

Finally, this does not apply to the next-gen-project in Cloud, where epics are not handled the same on boards and their workflow is also not available.

Radim Drinka
Atlassian Certified Technical Sales

If you need help from experts with the implementation or setup of Jira, or advice on how to use it most efficiently in your company, do not hesitate to contact us

Our Atlassian solutions