How do you track epics with stories being played across different projects?

[motherg]

Hi all,

I've got what I thought would be a pretty common scenario....but it seems that might not be the case.

So you've got your Epic and this has stories. The epic is in one project and the stories are all being played out across other projects. There seems to be absolutely no way to track an epic on the RapidBoard if the stories aren't being played it in it's project - am I just being thick or is there a way of achieving this?

I've tried a few things, with the final attempt being creating a Swimlane with a customn query on the rapidboard (having run the query in the issue navigator first to make sure it returns results) but have got nothing, I'm now out of ideas.

You may be thinking "why on earth are you playing your epics across different projects" - here's an answer that should help:

• We use JIRA Projects to reflect our teams
• Each team works on one main product
• Some "Projects" (in the sense of a work project, not a JIRA project, something that is a deliverable end to end project) require changes to multiple products, therefore multiple teams work on the one project
• In scenarios like this, the stories that each team need to play are put in their backlogs (which means putting it in to their JIRA project)
• The epics remain in a project where they were created
• We do this in Pivotal Tracker at the moment and are attempting to replicate the functionality in Greenhopper
• Ideally we don't want to have to create another JIRA project (and thus another Rapidboard) for each cross team project as we'll lose visibility within the team. It adds complication and the devs won't update it.

[J · Accepted solution]

Hi Mother Goose! I'm glad you've found a solution, but I'm curious why pointing your board to two projects didn't work for you?

[motherg]

Becase I hadn't thought of that...doh! I'd just update the query to include both projects, right?

[Nathan Mitchell]

Lots of great food for thought and whilst I think our scenario is similar I am not sure it is the same, hoping it is though as an out of the box that I'm not aware of would be great :)

Current Scenario

Master Project

The Master Project has been created to track cross functional/product requirements using a KANBAN board. All issues are created as Epics, triaged to understand requirements and then high level design options created.

Once a high level design option has been validated and agreed with the business the necessary stories are raised and scoped under the different product projects, these are facilitated by different teams, and linked back to the Master Epic.

Therefore a Master Epic could have 1 or more linked stories from across different product projects

Product Project 1 - Product A

Product Project 2 - Product B

Product Project 3 - Integration

Example Scenario

Master Epic (MAS-001) created and has story (ProdA-003) linked

Master Epic (MAS-002) created and has stories (ProdA-007) and (ProdB-009) linked

Master Epic (MAS-003) created and has stories (ProdA-005), (ProdB-003) and (INT-002) linked

Requirement

We need to be able to easily summate all 3 Epics, linked stories and workflow statuses into

1 - a single view in Jira for tracking and monitoring purposes

2 - a single query that can be exported to Excel or an alternative for reporting purposes

[William Crighton [CCC]]

We solved this by using Jamie Echlin's script runner plugin and the following RapidBoard query:

Simple Rapid Board based on single project:

project = "My Project" or issueFunction 
in linkedIssuesOf("
project = 'My Project' and (sprint is empty or 
Sprint in (opensprints(), futuresprints()))", "has Epic") order by Rank 
ASC

'Complex' RapidBoard based on multiple projects

filter="Complex RapidBoard Filter" or issueFunction 
in linkedIssuesOf("filter='Complex RapidBoard Filter' and (sprint is empty or 
Sprint in (opensprints(), futuresprints()))", "has Epic") order by Rank 
ASC

This approach allows us to utilize the same rapid board filter syntax (changing the project name) and only shows the Epics that are associated with issues which are in the backlog, a future sprint, or a current sprint.

Note that applying this filter to a RapidBoard that was built automatically by JIRA Agile for a single project could result in displaying fewer Epics than the Board shows now - this is because the Epics which do not appear are not associated with any issues in your Board's backlog or current/future sprints.

Hope that helps someone.

-wc

[DebraE]

We are also using JIRA Projects to represent an Agile team and their stories. I'm considering building a separate JIRA project just to house Epics that are being worked by multiple teams and then having each team pull their JIRA project and the Epic project together into a Scrum Board. However, this will result in some teams seeing Epics which they are not working on and could make the Scrum Board Planning more difficult to manage. Suggestions?

[motherg]

Debra, ignore what I said, it was wrong - I'm trying to work it out now :)

[motherg]

Hi again Debra,

Worked it out! Hurrah.

Firstly, the answer as a concept - you can update the Rapid Boards query to return issues from two projects (as we know). But as that query is written in JQL you can update it to be whatever you want. In this case we want to taget issues that are related to an epic from another project as well as the stories from the main project.

Let's say this is the standard query for the board:

project = [Project 1]

And this is the new one

project = [Project 1] OR "Epic Link" = "Epic Name"

This will return all the issues from the main project and all those associated with the specific Epic from another project (this is why we use the Epic Link opperator as it finds issues with the link, Epic Name will just return the epic they are associated to). You can constrain the query further so that it only returns Stories (as you might might not want to see any bugs for example).

Does that help?

[motherg]

Hot damn, I'v worked it out!

I updated the filter of the rapidboard to return issues with the related to the epic I wanted by using the 'Epic Link' syntax.

I then created a swimlane using for the same epic link so I could seperate them out.

There query I originally had for the rapidboard was:

project = "Greenhopper Demo Project" ORDER BY RANK ASC

I modified it to be

(project = "Greenhopper Demo Project") OR ("Epic Link" = "[epic name]") ORDER BY RANK ASC

[francis]

How do you combine this with version management ?

[motherg]

We don't use versioning as we use Continuous Integration to do feature releases. When it's signed off it gets deployed to live therefore no versions are required.

[Peter Dittman]

We've worked through this issue. We have (business) projects that have work spanning multiple JIRA projects (execution/work centers/scrum teams).

We've introduced a new issuetype, called a workstream, that has children that are Epics. Epics are deliverables from the individual work centers (aka Scrum Teams using Agile boards). Workstreams are defined to span multiple JIRA projects and provide a view into the long-range plan of the business project.

The JIRA tooling was straightforward, new issuetype, new linktypes, some custom screens and a fair amount of evangelism. And, because we're using OnDemand, we had to buil some custom reporting tools (Workstream burndowns) via the REST API (the alternative would be a custom JIRA plugin).

It makes a nice story, shows where the business project is headed, yet enables the individual work centers to function relatively autonomously.

[l]

Hi Peter, Could you please guide us on how to create this workstream issue type in jira.

[l]

We really want to use this issue type in our jira. Our jira version is jira 6.3.4

[l]

Hi Peter, Could you please guide us on how to create this workstream issue type in jira.

[l]

Hi Peter, Could you please guide us on how to create this workstream issue type in jira.

[Peter Dittman]

Lynn_jira, apologies, I thought I'd posted a bit more on how this was done, but I don't see it listed... I'm no longer working at the company where we'd done this so I don't have screen shots available, but I'll help guide you through... we can also talk privately - contact me through Linkedin (Pgm Mgr at CA Technologies). Here goes... We extended the work item hierarchy by adding a new issue type - so there were tasks, stories, epics, and workstreams (workstreams were new). Create the new issue type, defining any specific screens and custom fields that are appropriate for your organization. To connect it into the hierarchy, you'll also need to create new linkstypes: Workstreams "are made up of" epics, and Epics "belong to" Workstreams. check out the Atlassian forums, etc. on how to do both of these steps. that was the JIRA tooling in a nutshell. From there, there was a fair amount of process change to get people to think beyond Epics. We introduced the constraint that Workstreams didn't span releases (we were on a quarterly release cadence), so we would go through release planning, identify the major features to be released and these were instantiated as the Workstreams. hope that helps a bit...

[jacky.lam]

Hello Peter

I have sent an LinkedIn connect request to you.

Hope to get some advice from you on Jira.

Thanks :)

Jacky  

[Andreas Haaken (APTIS)]

Hi, you mentoined something interesting: bq.Some "Projects" (in the sense of a work project, not a JIRA project, something that is a deliverable end to end project) This is what led us using Epics as projects (because they have a lifecycle then). And we also have issues inside the Epic spanning over several (JIRA-)projects: dev-Project, Support Project, common requests from emails and so on... We set Jira Projects as Container for customer projects, as they all have the same project level configs and permissions. The support projects are seperate, as there should be a basic access for the customer representatives and it yould be hard to configure these basic scenarios into one Jira Project. After some while we found that having some kind of issue (Epics so far) in the center of all connected information will be a good choice for clarity and we are able to use the agile features aswell. at last we just had a lack of comfortable information at the Epic itself, like: What is the Progress of teh whole Epic spanning over all issues and Jira Projects? How Much Story Points,estimated Time, Logged, Time do we have inthe Epic? You can get these infos, but its not fast and easy to get it.. So we decied to develop an new plugin, that does the job (Epic SumUp). one of our next steps may be to establish a new issue type for these real projects that are not epics, (naming is confusing then). What do you think of this solution to handle multiprojects without creating new Jira projects for every order? Is that next to your use case?

[motherg]

I like it! Very cool- might give this a go when I get the chance.

Is your special sauce of the open variety? Share the love ;-)

[Peter Dittman]

yea, no, sorry lad. Like I said, we're OnDemand, which limits what we can do - but it's straight forward - PERL script, accessing the REST API. Find the workstream of interest, then drill down and sum up, done, not done work, etc. Build up the % complete, etc.

The harder part (by far!) is changing behaviors so that people are consistently doing their release/long-range planning, so your Epics are a reasonable reflection of the work involved. If your Epics don't reasonably reflect the work to be done, then the % complete (burndown) is only part of the story...

HTH.

[motherg]

@Peter- have you got any screenshots showing a workstream issue in JIRA view with the child epics? I'm pretty sure I know how it'll look, just curious to see if it utilises the progress bars that Epics have in the Rapid View.

[Peter Dittman]

Mother-goose - sorry, no progress bars in native JIRA - that's part of the special sauce created with the REST API.

[DebraE]

Jeff - your scenario is similar to what I want to achieve. However, I have not come up with a solution to this yet. I will let you know if I do.

[DebraE]

Thanks! This is good information if I am trying to pull issues from different projects into one Board based on a single Epic, which I did get to work in my environment. However, what I am trying to do is define Epics in a centralized Epic project and pull them into all team boards so they don't have to each build epics for the same thing. But I also want to have the ability to limit what epics each board can see, as 30+ epics active at one time may be unmanageable for a single team when using the Scrum Plan mode, especially when only 5-10 may be relevant at any given point in time. Although I am able to update the filter for the board and pull in both the team project and the Epic project, I have not found a way to specify which Epics I want to display in the Epic list (ex. when issue count for that team > 0). If I can't limit the epics, I may just have to deal with the volume. Regardless, I should be able to use your suggestion above to build a board for the Epic project to pull in all issues related to the 30+ epics and use the Reports mode to monitor progress. Thanks for your help, Debra

[motherg]

Ahhhh I see what you mean now - you actually want the epic to appear in the list to the left hand side, not just have the stories associated with it in the backlog.

Yeah, it's a tricky one that - I'm not really sure there is an elegant solution to it apart from the individual teams not having to know how they are getting on with the epic, they just need to complete the stories. Does that make sense? Is it the case that you are the only person who's interested in seeing how much progress is being made with an epic, where the individual scrum teams just need to get crack on with the work assigned to them?

If they wanted to see how the epics were progressing they could have a look at the Epic project you have set up.

[Peter Dittman]

What ever happened to this discussion thread? We have the same pattern - projects associated with teams, and Epics that span teams. Not having Epics visible to the team at Sprint planning time is kinda counter to Agile transparency (visible context!).

[Kevin (Fake)]

I thought I'd resurrect this thread to see if anybody found a solution? I have configured a master agile board for 3 separate standalone projects. On that master board I have filters set up for each project - let's call them A, B and C - so that I can easily drill down. However, when I do that, the epics from the other 2 projects are still visible on the left-hand side of my screen. Ideally when I filter to only view Project A items I would only see the epics for Project A. Doable??

[Crystelle S]

It's not the most graceful solution but we've added teams as checkboxes to the Epic fields and are marking them so that the board filter for a team can pull in any Epic in all of JIRA based on the team being checked off. It also allows us to have more than one team see the Epic in their board.