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:
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
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.
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?
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.
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...
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 :)
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
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
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
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.
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??
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.
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...
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?
Stop: Articles and permission Article-writing permissions are given to Leaders, Marketplace Vendors, Solutions Partners, Atlassian Team members, and those who are Level 4 + above. But for any aspir...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events