Manage Epic stories in Jira/Greenhopper

[aravind sivaraman]

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

[davfive · Accepted solution]

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.

<th> </th><th> </th>

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

<colgroup><col width="24"><col></colgroup>

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:

1. Filter Stories to get different Views of the backlog.
2. 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.

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

[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

[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?

[pmorgan]

Hi Renjith - the guts of the issue is that we are using iPads often to work with Jira, and drag and drop is not always easy when there is a long list of epics - we have a bit of trouble scrolling up and down the list of epics on the planning board, as it does not always respond to the two-fingered scroll (sometimes, when doing the two-fingered scroll, epics are picked up - it's buggy). So we don't want that to be the *only* way you can manage epic links - there seems to be no way to edit these epic links other than drag and drop.

Also - some of the team have tried to specifiy the Epic when creating an issue - by typing into the "Epic/Theme" field - but all this does is bring up a list of labels (??). Using the 'linked issues' fields doesn't help either - it looks like the only way to create an Epic link is to drag and drop the story onto the Epic, in the planning board - is that right?

It's also not possible to see Epic links when viewing an issue - unless you look at the history tab and you can see where someone has made the link.

But - I LOVE using this functionality on my desktop, we use Epic links alll the time and feel it's a great piece of functionality - I just wish we could edit the Epic links manually on creation or when editing an issue.

Thanks :)

[Renjith Pillai]

• Ah, that explains. iPad - something for the GH team to have a look.
• Epic/Theme field is for the Classic boards, it is not used anymore for the new boards. And as Shaun said already, this link between Epics and stories is not the normal issue linking.
• This extra functionality to see the Epic while seeing the issue is in the pipeline as per Shaun's comment earlier.

[Lisa Rahder]

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

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

[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

[JessS]

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?

[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

[Rod Simpson]

I understand this hierarchy, but it isn't enforced by the system, so things can go all willy-nilly in a hurry.

Also, if epics can't be included in sprints, then why can you create sub-tasks under them? Those sub-tasks can never be included in a sprint to be worked on. This seems like a contradiction.

For what it's worth, the reason we like the sub-tasks feature is that it is a very convinient way of breaking down a ticket into smaller pieces. You can do it all from the same screen by clicking the "add subtask" button.

In contrast, the "add link" method of attaching stories to epics doesn't work as well because it doesn't all happen in one place. There is a lot more clicking / navigating between windows / remembering ticket numbers.

I think if this ease of use issue could be addressed, it would solve some problems.

[sclowes]

I'm not sure what you mean Rod.

Yes, you can add subtasks to an Epic, there's nothing we can do to restrict this JIRA feature. We wouldn't recommend it though, and there is no UI in GreenHopper to do so.

In the next version of GreenHopper you can click on the Epic then click 'Add Story', to easily add sub stories to the Epic. In the current version you can still do it on the same screen by dragging and dropping them on to the Epic. I'm not 100% sure if you're using the new Epic labs features, the only way to create Epic links in the new implementation is by dragging and dropping the story on to the Epic in Plan mode. The new method does not use issue numbers or the Epic/Theme field.

Cheers,
Shaun

[Rod Simpson]

Shaun,

I appreciate your continued efforts to help.

We are using the Epic labs feature, and see the drag / drop behavior you describe. But compare this workflow to creating a subtask. With a subtask, you simply click a button, create the task, and you are done. No dragging. no linking. It is very easy.

In contrast, if I want to create a new story and link it to an epic, it is quite an ordeal. I must first create the story. Then, I have to dig through the backlog to find the newly created story, which is usually at the bottom. I don't know what kind of backlog you guys have, but we have hundreds of stories. So dragging the new story up to the epic is a pain, and takes a while. So sure, I can make a filter to show only recent stories, but then I have to click it on and off each time. Then, once I finally do drag it up to the epic, that relationship only shows up in this rapid board view. It exists nowhere else. So, now we have to create links, which is a bunch more clicking and typeing.

So, my hope is that that since you won't let people use subtasks, that you will make creating stories and adding/linking them to epics just as easy.

It sounds like you are suggesting that this feature will be available in the next release, which would be great. When can we expect it?

thank you,

Rod

[sclowes]

In the next version (6.0.8) the Epic panel will 'stalk' and always be visible. You will also get the 'Create Issue' link for each Epic to immediately create an issue.

You can see what this looks like on our public backlog:

https://jira.atlassian.com/secure/RapidBoard.jspa?rapidView=96&view=planning&selectedIssue=GHS-6541

6.0.8 should be released for download in a couple of days, it will available in OnDemand in a couple of weeks.

Cheers,
Shaun

[Rod Simpson]

Shaun,

I don't see the 'create issue' link on the epics on the link you sent. Is that because I don't have permissions?

Also, it looks like you still can't have the epic display in the right hand panel. If you click on the epic from the epic panel, it filters the tickets in the backlog and the sprint, but the right hand panel still shows the last ticket you were looking at. Is there a trick to this?

Thanks!

[sclowes]

Yes, you're probably not seeing the add issue section because you don't have permission. A screenshot is below.

You still can't show Epics in the backlog, as discussed we don't have any plans to allow that.

Thanks,
Shaun

[Rod Simpson]

Shaun,

When I say that the epics dont appear in the right panel when you click them, I mean the panel all the way to the right. There are three panels now, epic, backlog, and the right hand panel which is like a detail view. I would expect that clicking on an epic in the left hand epic panel would cause the epic to be displayed in the right hand (not middle) detail panel. The only way I have been able to figure out how to do this is to change the url.

Is there some other way to do it?

[sclowes]

No, as I said there's currently no way to open the detail view for the Epic. My comment:

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

In hindsight I've looked at the backlog and we do plan on making the link on the left open the Epic in the detail view.

Thanks,
Shaun

[Rod Simpson]

Great, thank you for clarifying.

[Philbert]

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.

[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

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

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

[James Sandlin]

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

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

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

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

[aravind sivaraman]

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

[James Sandlin]

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