nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

epic management in JIRA software

Prem Chudzinski _extensi_

Hi everyone,

I'm trying to improve our boards and I'm lost with the concept of epics.

We support our software development. process using jira.

Our scenario:

1. We use kanban boards and the swimlanes are epic based.

2. Our epics represent product sections/parts

3. Tasks (Story, Bugs, CR) represent features whithin product sections

4. We don't use subtasks at the moment

5. We use components to group tasks as well

6. Statueses: Backlog->Selected->In Progress->ReadyTo Test->DocumentMe->Done

7. We use versions and releases

Example:

Epic: Product Built-In tutorial

Story\Task: Tutorial for the admin page

Components: admin page, tutorials & help

Issues:

We have to maintain two separate boards one for epic one for the stories
Epics can't be always included in the release as they are too generic and may be extended later on - that would require reopening.
We had no epics at the beginning but it was hard to maintain board swimlanes which were created using JQL. I had around 50 entries which were component based - that was the reason we went for epics.
With no epics we'd have to use subtasks which have similar limitations - in this case our swimlanes would have to be Story Based and we'd endup with the same issue.

Any advice?

I'm looking for some real life examples/use cases.

Comments

Nic Brough -Adaptavist-

Most of that sounds ok, with the exception of point 2. An Epic should not be a product section, it should be a (very large) story which has an eventual end.

Moving on to your reported issues

I'm not sure why you need separate boards. Even if you do, I'm not really certain why it should be a problem, as I often tell people to use many boards (Although I do say one Scrum board for planning across the team, and then as many Kanban as works)
Epics would not normally be included in a release. You just close them when they've finished (all stories complete)
50 Swimlanes is way too large, I agree. I'd suggest looking at the boards instead, it sounds like they're trying to include too much
(last point is probably just a result of the first three, although I'm not sure what the actual limitation is)

Prem Chudzinski _extensi_

Why epics should not represent a piece of the product?

Lets take a www as a product example:

Themes ->Something super big

Epics -> Admin Page, Login Page, Search Engine

Story->Delete users on admin page, Clear cache on Admin Page, integrate google engine in the search engine...

Components-> for stories only like user management, ect..

Regarding swimlanes: yes 50 swimlanes to represent "epics" was way too much thats why I use swimlanes by epics

So the issue is that we do releases using stories but epics have to te tracked manually on a separate board.

Epic details on a board don't show included Stories/Tasks so its hard to tell which stories are included unless you open the ticket in a separate window.

Using the given www example how would you design the structure of the epics/story/components?

Sam Hall_h1otcf

Why epics should not represent a piece of the product?

A way to think about Epics is as representing a big chuck of work needed to make the product do something for a user (or set of users).

i.e. Epics represent (big) blocks of work required to build the product. They don't represent the product or pieces of the product itself.

Epics are exactly the same as stories, just larger.

A good Epic should have clear acceptance criteria and scope, just like a good story - a clear definition of what needs to be done for the work to be considered complete.

If you just have an Epic 'Admin Page', it's not enough. This doesn't tell us what the Epic is really trying to achieve. It could live forever as you decide to make more and more changes.

Instead, the Epic would be better defined as something more definite. To give a trivial example:

"Core Admin Functions:
As an admin, I want an admin page allowing me to perform important stuff. As a minimum, to get the site live, I need to create, update and delete user details and clear the system cache so that everything runs smoothly."

This then breaks down into the stories and tasks needed to build all the functionality defined in the Epic. When they're all done, the original scope of the Epic can be revisited. If it is all delivered and the admin can do what was agreed, then the Epic is complete and not to be reopened again.

Later on, when the admin needs more functionality, then it's a new Epic. For example "Enhanced Admin Functions: As an admin, I want more powers...etc.".

In your example, I'd have "Admin Page", "Login Page", etc as components and then use Epics to represent various large chunks of work related to each component.

scherbank

This, for sure, is the only my personal opinion but I guess all stuff like epics and stories came from scrum process and in Kanban approach you can threat them the way you like.

Foe example EPIC are color specific and I think there are many cases you can use color as a signal (Kanban was founded like signal system).

When you create swimlanes based on epic you might lost manageability and visibility because of many aspects: two much swimlanes never fit the screen and user may faced issues when need to hide some of them o scroll two much. The idea of swimlane is more or less the expedite or make the task over limit.

I would recommend you to set quick filters instead.

Other than that Components usually more stable so in your case is better to use them in swimlane config.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

board

epic