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; } } }

Manage Epic stories in Jira/Greenhopper

aravind sivaram

My company is using the greenhopper(v5.10) plugin of jira version to do agile project management. We practice scum.

One of our pain points has been managing Epics via greenhopper.

what we want is

1) Epics should contain a field to contain SWAG and also should have a field to show story point roll up of all its children stories.

2) The parent-child sort of relationship between epics and its user stories should be visible/available both from epic and the child. (e.g. child should show the parent or epic, the epic should show all children user stories).

3) The Epic should not be visible in a version like 'product backlog', so the story points are not double counted.

4)Epic's children can ranked in any fashion in the business backlog. The ordering of the user stories within an epic should not be a concern.

We did do some research online, through atlassian's online documentation

https://confluence.atlassian.com/display/GH/Working+with+Epics

http://stackoverflow.com/tags/greenhopper/hot

looks the recommendation is to use the 'scrum' project template and that should help us.

We tried it, it looks ok but it seems items (2) and (3) hard to achieve

so the question

is there any recommended practice on how to manage epics using jira/greenhopper ? any other external plugins needed etc. ?

Accepted answers

davfive

This is a writeup I did to train on how we use it internally, it covers most of what is discussed above but gives details on the implementation. There is some complexity here, but with Shaun's comment above about using issue links as a positive future direction and them nailing the existing UI from a functional perspective, I believe that when they deliver epics at some point in the future, much of the complexity will be eliminated.

Also, one of the benefits of using issue links is that you can break-down the epics in jira itself if you like since all of the links are visible from there.

Enjoy,

David

PS, this is a cut/paste from our confluence so some of the images are pushed off to the right as they are in tables. Sorry.

Using Greenhopper Boards

Greenhopper Boards, previously called Rapid Boards, have come a long way since they were first introduced earlier this year.

Getting Story Hierarchy and Epics using Issue Linking

The Boards do not yet have native support for Epics (or child stories). To address this, we have taken advantage of JIRA's Issue Linking feature. We have added a 'Story Hierarchy' link type with named links of 'Story's Parent' (outbound) and 'Sub-Stories' (inbound).

This does a number of things for us. First, it allows us to have an explicit, visible link between stories and their parents that is visible and manageable both from JIRA and from the Board itself:

JIRA View

Greenhopper View

This allows us not only to break Epic's down into stories, but also allows us to break Stories into Stories. We haven't done this, but we could create a new Issue Type of Theme and apply the same principles to that.

Secondly, with the use of the free Craftforge JQL Functions Plugin or the paid JQL J-Tricks Plugin, queries can be done based on the existence of Issue Links. We use this both for the Sprint board as well as for the Quick Filters on the Planning board, both of which will be discussed later.

To learn how to create and setup new boards for this, see Greenhopper Board Configuration.

Given that as a backdrop, let's walk through each of the Scrum activities and how to do them using the Greenhopper Boards.

Taking a Quick Look at the two Boards

We have created two separate GH Boards to manage our product backlog and sprints: a planning and a sprint board.

Here's the activities that they cover:

How we use the Sprint Board

The Sprint board is used primarily by the Scrum Team in the standard Greenhopper way. A description of this can be found on Atlassian's Greenhopper Page.

How we use the Planning Board

The Planning board is used primarily by the Product Owner to create and build out Epics and during the Backlog Grooming to estimate and breakdown Epics into Stories. Let's look at it a bit closer.

On the Planning Board, you will find all Epics and Stories that exist for the given project (that haven't already been resolved).

Why a second Board?

There are actually two reasons for a second board:

The filters needed during the Backlog Grooming and for the Product Owner are much different that what interests a team during a sprint (we go into filters below)
When Adding a Sprint and dragging the bar down to put stories into it, filtered stories get added even though you can't see them. So if we hide all of the epics, or other stories with Sub-Stories which shouldn't go into a sprint, they'll get inadvertently added to the sprint, thus ruining the integrity of the backlog.

So here's the Planning Board. There are 2 primary activities on this board:

Filter Stories to get different Views of the backlog.
Break large Stories and Epics into smaller Sub-Stories

Filtering

Here is an overview of what you get with the filtering we have setup:

In general, the only filters that need to change team to team would be the releases. A quick view, for the curious, of the queries behind the filters can be found in the Board Configuration on the Quick Filters tab and are:

Breaking Down Stories

Breaking down stories is probably one of the most common activities. Whether it's breaking down Epics into Stories or Stories into Tasks, it's done all the time and should be drop-dead simple.

Without an existing way yet to deal with Epics in Greenhopper, we break down Epics and Stories using Issue Links and they show up conveniently in the right sidebar of the Board like:

To create a new Sub-Story, click "Create Issue" in the upper right and make sure to fill out the Linked Issues field with the "Story's Parent":

To link a story to an existing story (or Epic as the case may be), click on the story from the Board to that it's details are visible in the right sidebar, then use the Tool menu and click Link, or use the Add Link button in the sidebar. From there just select the Story or Epic you want to link with.

That's about it for this walkthrough. We hope you enjoy the new Boards.

All comments

James Sandlin2

Unfortunately, this is a limitation to Greenhopper. Long term project planning is very lacking in Greenhopper.

aravind sivaram

Thanks James, Do you know if greenhopper 6 addresses some of this ?

sclowes

Hi Aravind,

Some of what you are asking for is achievable today.

1) Epics should contain a field to contain SWAG and also should have a field to show story point roll up of all its children stories.

You can easily create a new numeric custom field called SWAG and associate this with the Epic issue type. However in what I'll describe below the roll up is not going to be easily possible.

Simply create issues of type epic then 'link' the epic to the children stories. You will then get bidirectional links from the epic to the children.

3) The Epic should not be visible in a version like 'product backlog', so the story points are not double counted.

You can configure an Epic rapid board with a filter like 'project = x and issuetype = Epic' (this will show only the epics), and a Team rapid board with 'project = x and issuetype != Epic' which can be used for actually executing sprints.

Your Epic rapid board can be configured to use the SWAG field as the estimation unit so you can work with those values easily.

4)Epic's children can ranked in any fashion in the business backlog. The ordering of the user stories within an epic should not be a concern.

The backlog in the Epic rapid board described above will be completely separate from the backlog in the Team rapid board, you can rank completely independently.

We plan on doing further work to make working with Epics easier in the near future, but you might like to consider the above approach.

Thanks,
Shaun

James Sandlin2

I have attempted something very similar & it does work as Shaun explains. However:

1) When an epic has stories under it, the total points of stories should sum up into the epic & then display a remaining field as each story is completed. A manager should be able to watch an epic & know overall status. This doesn't happen.

2) When using Greenhopper, there is a field to specify an Epic. When a user defines the Epic in Greenhopper, they should not be required to then go into the same ticket & link it to the Epic. Users will not perform the same action twice.

I have found the 2 best ways to accomplish this task (each of which have their own problems) are:

a) Enable Subtasks then pretend a Story is an Epic

-- bad solution but satisfies the linking of tickets mentioned by Shaun

b) Create a "release" for each long term project (epic). Stories are then placed into 2 releases: the sprint they are completed && the "epic release". The problem here is: when you drag the story in Greenhopper into a specific sprint, it assigns said story to said release therefore removing the "epic release".

c) Use labels, which is how I'm doing it currently. Have a common label you use on each story then create a filter for said label. Finally, place said label into Greenhopper as a Context. You can then view / organize items within said "Epic".

sclowes

Just a quick note, the 'field to link an Epic in GreenHopper' is only used in the classic boards, the approach we will use when enhancing the new boards with further Epic support will be to use issue links. If you ignore the Epic field and use links you will not need to enter the information twice.

Agreed that Lables are actually a good approach.

Thanks,
Shaun

davfive

Also, one of the benefits of using issue links is that you can break-down the epics in jira itself if you like since all of the links are visible from there.

Enjoy,

David

PS, this is a cut/paste from our confluence so some of the images are pushed off to the right as they are in tables. Sorry.

Using Greenhopper Boards

Greenhopper Boards, previously called Rapid Boards, have come a long way since they were first introduced earlier this year.

Getting Story Hierarchy and Epics using Issue Linking

JIRA View

Greenhopper View

To learn how to create and setup new boards for this, see Greenhopper Board Configuration.

Given that as a backdrop, let's walk through each of the Scrum activities and how to do them using the Greenhopper Boards.

Taking a Quick Look at the two Boards

We have created two separate GH Boards to manage our product backlog and sprints: a planning and a sprint board.

Here's the activities that they cover:

How we use the Sprint Board

The Sprint board is used primarily by the Scrum Team in the standard Greenhopper way. A description of this can be found on Atlassian's Greenhopper Page.

How we use the Planning Board

The Planning board is used primarily by the Product Owner to create and build out Epics and during the Backlog Grooming to estimate and breakdown Epics into Stories. Let's look at it a bit closer.

On the Planning Board, you will find all Epics and Stories that exist for the given project (that haven't already been resolved).

Why a second Board?

There are actually two reasons for a second board:

The filters needed during the Backlog Grooming and for the Product Owner are much different that what interests a team during a sprint (we go into filters below)
When Adding a Sprint and dragging the bar down to put stories into it, filtered stories get added even though you can't see them. So if we hide all of the epics, or other stories with Sub-Stories which shouldn't go into a sprint, they'll get inadvertently added to the sprint, thus ruining the integrity of the backlog.

So here's the Planning Board. There are 2 primary activities on this board:

Filter Stories to get different Views of the backlog.
Break large Stories and Epics into smaller Sub-Stories

Filtering

Here is an overview of what you get with the filtering we have setup:

Breaking Down Stories

Breaking down stories is probably one of the most common activities. Whether it's breaking down Epics into Stories or Stories into Tasks, it's done all the time and should be drop-dead simple.

Without an existing way yet to deal with Epics in Greenhopper, we break down Epics and Stories using Issue Links and they show up conveniently in the right sidebar of the Board like:

To create a new Sub-Story, click "Create Issue" in the upper right and make sure to fill out the Linked Issues field with the "Story's Parent":

That's about it for this walkthrough. We hope you enjoy the new Boards.

Doug Levitt

Davfive, thanks for posting this solution.

Questions:

1. Does the Product Owner "specify" priority on the Planning Board (by sequencing the items in the BackLog)? If so, how does that sequence get "transferred" to the Sprint Board?

2. Are you manually setting the "Fixed In" version for each item (to the release you expect it to get included in)? Or, is GreenHopper setting this (once items are dragged into a Sprint)?

3. Could you elaborate on: "When Adding a Sprint and dragging the bar down to put stories into it, filtered stories get added even though you can't see them. So if we hide all of the epics, or other stories with Sub-Stories which shouldn't go into a sprint, they'll get inadvertently added to the sprint, thus ruining the integrity of the backlog"? I don't understand what filters are being used on the Sprint Board that would hide things.

Thanks!

Doug

davfive

A1. Because greenhopper uses a global ranking system, changes on one board are reflected in the other so this is not a problem. A2. Yes, we are manually setting Fix Version. With the Rapid Board's ability to have multiple projects shown on the board, it can't know which Fix Version or release each issue is going into so you have to do it yourself. A3. Sure, there are current no filters on the sprint board because of this, the problem would arise in the case where I merged the two boards and the epics could be then hidden on the sprint board. Actually, I am considering merging our boards internally to simplify but then there would need to be a rule that they don't drag down the bar, One addition that would be nice on the boards is to be else to add a description at the top where we could put information or instructions on using the board.

Norman Abramovitz

Greenhopper 6.0.6 just introduced some new features(labs) related to epics, but make sure you read the release notes before attempting to use them since there are caveats and missing features.

Rod Simpson

Does anyone know what kind of timeline we are looking at before the linking / cross linking between epics and child stories will happen automatically (when you drag the story to the epic on the rapid planning board)?

Nicholas Muldoon

Hi Rod,

This linking does happen automatically today. What are you missing?

Thank Rod,
Nicholas Muldoon
@GreenHopperTeam

Rod Simpson

Nicholas,

Thank you for answering.

From what I can tell, there are three types of relationships:

1. Linking - "Blocked by, Relates to, etc." This link is created by choosing "link" from the "more actions" dropdown when viewing a ticket.

2. Sub taks - create a subtask in a ticket

3. Invisible "epic" link - in rapid board, drag ticket to epic and this "link" is created.

The problem is that if you use method #3, these links never show up anywhere on the ticket (only on the rapid board, which is not good). In the workflow described by davefive, he mentions this wonky workaround, which is to explicitly add links "is child of, is parent of" to epics / children. So, you have to create the child, drag it to the epic, add a "is child of" link to the child, add a "is parent of" link to the parent, then install some third party plugin so that you can see them.

I assumed that this was just a temporary thing and that the team is working to fix it. Maybe there is some other way that all this should be used? I saw on another post that subtasks will soon be visible, which would be great and would solve the problem.

So to recap, dragging a ticket to an epic on the rapid board should automatically create child / parent relationships such that the child ticket is visible in the normal view (e.g. https://company.atlassian.net/browse/MYPROJECT-64), thereby removing the need to do this manually.

Philbert1

I concur with Rod Simpson. I have run into the exact same problem. This is not consistent with the way Technical Tasks work, even though the User Story - Epic link is the same type of relation.

sclowes

Hi Rod,

The link between an Epic and its children is actually achieved using issue links, but they are system level links so they do not appear as links of the type you see in View Issue. We will introduce a separate panel to show the stories of an Epic in the view issue page in the future.

Regarding sub tasks being visible, I'm not sure what you mean, they have been visible in releases for a long time (in the sub-tasks tab on Plan mode, as cards on Work mode).

Thanks,
Shaun

Rod Simpson

Nicholas, thank you for replying.

I fully understand that subtasks can be seen if you can get the epic to be displayed. However, there are many problems with this:

1. Subtasks don't show in the backlog (for example "technical tasks"). This means they can't be put into a sprint, which makes them kind of pointless.

2. There is a problem getting Epics to show in the panel on the right. I have found that the only way to get them to be displayed is to modify the url so that selectedIssue = epic number. clicking on the epic doesn't show it.

3. Epics only show in the new "epics" panel on the left. This panel is not very helpful. First, it only shows this new epic "label" instead of the regular ticket summary (like all the rest of the tickets). Not sure what the value is there. Also, the panel doesn't even show the ticket number. What? Maybe you are used to teams with only a few epics, but we have 40 or so. Not having this basic information makes this panel useless.

4. Epics do not show up in the backlog with the rest of the tickets. I applaud atlassian for trying to re-think this, but come on, just show the tickets in the backlog so we can get on with business. Change it later once you actually work it all out.

This has been a frustrating experience, and I just don't think it needed to be.

sclowes

Hi Rod,

I assume you're referring to my response rather than Nick's so I'll reply.

1. The sub tasks are automatically included in to the sprint with their parent issue, you don't need to do anything other than include the parent

2. We are not sure if we'll implement a detail view for Epics, we think we will but the use cases aren't 100% clear, most users we have asked use Epics simply as containers

3. We need a short name for an Epic that we can display directly on the issue in the backlog, because the summary is usually too long we implemented the label. The panel will show the ticket number with a link in the next release

4. We will not be showing the Epics in the backlog, they are a higher level organisational structure.

I apologise that you find it 'frustrating'. For what it's worth we release features in labs when they are unfinished so we can get feedback, we'd recommend not using labs features if you do not want to experience rough edges.

Thanks,
Shaun

Rod Simpson

Shaun,

Thank you for replying.

1. We generally don't want to include an entire epic in a sprint since, as you said, they are a higher level construct. We want to include some / all of the subtasks, which might be assigned to different developers. So including the whole epic is basically useless to us.

2. My opinion: Epics should be as easily accessable as other stories. Not sure why that would even be a question.

3. My opinion again: If the summary / ticket numbers don't fit, redesign the panel, don't create some new random label that has no relevance to the entire rest of the system.

4. My opinion once more: Putting epics in the backlog would be a far better solution than the epic panel. Perhaps it will improve with future releases.

My frustration is not with the labs "epic" feature. My frustration comes from being directed to the rapid boards when they are clearly not ready for production use. Without the "epic" labs feature, there isn't a way to use epics at all. Not sure how directing people away from the classic view was a sage decision at this point. Especially the way the message was worded that guided you to the rapid boards. You guys jumped the gun on that one.

I get where the rapid boards are headed, and I think it is great. In time, it will be a great product. I can tell that the company is trying hard and that the developers care. My guess is that it was an "executive" or a "marketing" decision to push forward when they did.

Knowing what I know now, I probably would have held off until the rapid board is more mature. But we aren't going back now. Hopefully fixes are on the horizon.

sclowes

Hi Rod,

The intention is that Epics own Stories then Stories own Tasks, as a result the idea is that Epics do not get included in to Sprints but Stories do (and bring their sub tasks with them).

Thanks,
Shaun

pmorgan

The lack of an actual link in the issue itself is causing issues for us right now - i can see 'epic link' in the [history] panel of the issue, but am unable to edit that. Manually creating an issue link to the epic doesn't show on the planning board! So this is causing many headaches :-(

Renjith Pillai

Could you please clarify why you would like to manually create the Epic link while you can easily create it by dragging and droping into the Epic in GreenHopper itself?

unknown

Is there any way of filtering for all of the stories which are linked to a particular epic? E.g. could I filter for all stories which are attached to the 'Apples' epic? What would this query look like?

Peter Dittman

This was a great writeup/thread - Aravind, thanks for asking the question, Davfive - thanks for that great usage model...

We are struggling with this same impedence issue between GH & Jira - Greenhopper is still a plugin, not an integrated part of Jira...

Drag/drop to make a story a child of an Epic is nice (on the board), but the underlying JIRA issue isn't updated with the bidirectional links. Thus, when looking at the issue in Jira (which one is obliged to do frequently, especially on the dashboards), one can't tell where it sits in the story heirarchy. This is a basic need. Having to establish the "issue links" manually, after already dragging/dropping on the board is a non-starter (manual means prone to errors/gaps).

And, until that issue link is automatic, there's no simple way to trust a sizing rollup to get a real sense of how 'complete' an epic might be (which is a basic first step on an Epic burndown chart)... Again, critical missing capability...

yes, we'll continue with workarounds, but the business wants to know when things will be done, we can't give them an easy way to see that (without manual intervention)...

sorry, don't mean to b*$ch, just putting in a plug for tighter/seamless integration between the two...

sclowes

Hi Peter,

Have you seen the new view of the stores in an Epic in the JIRA view issue screen in GreenHopper 6.1.3? Take a look at the release notes for more.

Thanks,
Shaun

Peter Dittman

Shaun,

thanks for the comment/note... Great to see those upcoming items, both the automatic creation of the story hierarchy in the JIRA issue (epic) AND the creation of the EPIC Report (Epic burndown)... that's what I was talking about... Unfortunately, we're using the on-demand version, so I guess we'll have to wait for it to make it to that platform...

thanks again.

Lisa Rahder

Try Structure: http://almworks.com/structure/overview.html

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

epic