Trying to figure out the best way to create an agile board that will * Contain epics from one project, call it "Project A" * Display the stories from other projects that are associated with those epics Put a different way: a central "Team A" creates epics in "Project A", but the tasks/stories associated with that epic belong to teams B, C, D, E. Team A wants a status view of the progress of those epics. Thanks for any suggestions.

@Chris Stemen, I would like to test the scheme you proposed. Are you still willing to share the script for the "Sub-Task Team" field? I would really appreciate it.

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

Create a board to track issues from other teams

Mike Wilson

Trying to figure out the best way to create an agile board that will

Contain epics from one project, call it "Project A"
Display the stories from other projects that are associated with those epics

Put a different way: a central "Team A" creates epics in "Project A", but the tasks/stories associated with that epic belong to teams B, C, D, E. Team A wants a status view of the progress of those epics.

Thanks for any suggestions.

Accepted answers

All comments

Nicolas Bourdages

Sounds feasible if you have the Scriptrunner plugin.

https://jamieechlin.atlassian.net/wiki/display/GRV/Scripted+JQL+Functions

Your filter query should look something like this:

project = A AND issuetype = Epic OR project in (B, C, D, E) AND issueFunction in hasLinkType("Epic-Story Link")

Note that this doesn't do 100% exactly what you've asked for, in the sense that it doesn't ensure that the issues from B, C, D, E have an Epic from project A, just that they have an Epic. With a bit more tweaking, i'm sure you'll be able to refine this, or avoid using Epics that are not from project A.

Maybe the perfect solution would be to script your own function that would go like this: hasEpic("project = A"), and that would pick up issues that have an Epic belonging to project A.

Good luck!

Chris Stemen

We have been managing multiple teams on multiple projects in JIRA for over 2 years now, and have settled on a solution that works really well for us. Rather than having our board filters setup by project (i.e. Project = "A" AND blah blah blah), we use 3 custom fields to manage teams.

1.) A single select drop-down custom field called "Team Assigned", that is required on all issues for specified projects.

2.) A custom multi-select checkbox field called "Teams Included". This field is only on the Epic screen and it lists all teams. I check all teams that will be working on an epic.

3.) A scripted field called "Sub-Task Team". This is a field just for subtasks that calculates the parent team. I can provide the script for this if you want.

Here is how I use these three fields to manage projects. When a team is formed, the board JQL filter is setup to the following (for this example I will use the "UserExperience" team):

"Team Assigned" = "UserExperience" OR "Teams Included" = "UserExperience" OR "Sub-Task Team" ~ "UserExperience"

This means any issue created in any project will show on their board when their team is selected, as well as any Epic where their team has a check in the box, and will also grab all sub-tasks, as the calculated field will inherit the team value automatically from the parent (we have a rule that the team who owns the parent story works on the the sub-tasks - this prevents multiple teams from working off the same backlog with multiple POs. Every team should have their own PO and prioritized backlog per Agile). Incidentally, I have also created a "Team Requesting" field to track who sent what to each team. They use this field on dashboards to see in-bound/out-bound requests and track blockers so they can stay informed without digging into other team's boards or trying to setup complicated linked issue systems.

The major benefit of this system is that I can use JIRA "Projects" correctly, where they are just actual projects, and the team boards can see any issues assigned to that team from any project. Further, their list of Epics are filtered to only see the Epics they care about. To your point about seeing an Epic across teams, I have setup Master Boards that see all issues in a project, for release planning, and can always see the Epic progress across all the teams that work on that Epic.

We have found that for most practical environments, setting up a board filter for a team based on the Project is just too restrictive, but the beauty of JIRA is you can customize that board to look at everything the team needs to see regardless of Project - very powerful!

I hope this helps.

Chris Stemen

Mike Wilson

Thanks, Nicolas and Chris.

nycjoker

@Chris Stemen, this sounds like a great solution. Can you elaborate a bit more on the process you follow from creation of an Epic involving multiple teams to Stories for those teams? If multiple teams are involved in achieving an Epic, how are you managing dependencies?

Thanks!

Chris Stemen

Sure Edward. Let me first explain how we have organized JIRA, as we have evolved since this post.

We are practicing a majority of the organizational aspects of SAFe, so we have a 3 tiered system in JIRA to allow communication from our executive level (level 1), through program management at the department level (level 2), and down to the teams (level 3).

Our top level is our portfolio of all projects (including releases). We use the Atlassian "Project Central" idea for that. If you happened to attend the last summit (2015) you will be familiar with this concept. If not, see here. The Project Central board is reviewed by executive management (as well as anyone else who is interested), where they can get regular updates on projects at a high level, and can prioritize projects for us so we can get feedback from them and they from us (the PMO is responsible for making sure PC records are kept up to date). They do not follow all projects in PC, just the ones they need to.

Our PMO concerns itself with the 2nd tier, which is a set of special JIRA projects called Roadmaps. Each department in the company has a Roadmap project. Each Roadmap project has a scrum board that has sprints setup for a quarter (i.e. Q1 2016, Q2 2016, and so on). All major feature work is written here at a high level and prioritized by quarter and importance/value, and is expected to be broken down by teams. This board is great for managing and reporting on deliverables for each department at a quarter's level of visibility - which is how we plan and budget (like many companies...hopefully!). There will be many release related or company internal projects that will need to be linked to a department Roadmap project/board. We create high level features/project work in the Roadmap constantly, and link them to Roadmap pages in Confluence for detailed information. This is where teams get their feature requirements.

Every Roadmap issue has the "Teams Included" field mentioned in my first post. My group (PMO) and my Scrum Masters (we include SMs in our PMO as they are coaching the teams through their planning process) review the Roadmaps each week and identify work that needs to be broken down by teams (in priority order). Every story in the Roadmap has a Definition of Done, which are a set of sub-tasks under the Roadmap issue that dictate when it is "complete". Some examples are: "PO Scoping", "Team Breakdown and Story Writing", "Team Estimation", "Development", and "PO Acceptance". The work that is broken down (one of the DoD steps of the Roadmap issue as I mentioned) gets created on the 3rd tier which is where all of our release train projects actually live. This is where the epics go, which you asked about in your question. I'll get to that shortly...

The 3rd tier is a the set of all projects in JIRA created for our release trains (SAFe) and various departmental internal projects. This is where the team boards concept I mentioned in the first post are getting work (the "Team Assigned" and "Sub-task Team" fields are relevant). I use a system of standard workflows to govern these projects, so whenever a new one is spun up, it will have the workflow restrictions already in place to get moving with the Roadmap process. One of the most important workflow rules is that any work broken down by a team in a 3rd tier project cannot be moved into "In Progress" until that story (or parent story if your Definition of Done is covered through sub-tasks, which is how we do it) is linked to a Roadmap issue. This keeps the 3 tiered system in line, and allows me to run reports on dashboards indicating how we are doing with our planning, overall project completeness (I use the version report and pie chart report by status extensively here), etc.

So - let's get to your question about how to break down epics and coordinate across multiple teams. During the "work breakdown" step for a high level feature on the Roadmap board, one or many teams may be involved. We believe in regular planning vs mega-planning periods, so whenever a new Roadmap issue hits the board, we bring it to the Scrum of Scrums and notify the team Scrum Masters involved that a feature is ready for them to break down. They review the issue and decide if an Architecture Committee review meeting is necessary (we have a sub-workflow for our stories on the 3rd tier that put them in an ARC Review loop so our Architectures and Tech Leads know about an issue that requires coordinated review and decisions). Coming out of this process, the Architect or a designated Tech Lead will create the set of epics necessary, and select the appropriate teams involved so it shows on their boards (using that "Teams Included" field). During backlog grooming, the teams will write stories and breakdown the work with their PO. All of these stories will be under the Epic, but they also must be linked to the Roadmap story as well. This allows us to view all work associated with a high level issue from the Roadmap board. As soon as estimates are done, the PMO team uses JIRA Portfolio to update the release plan, so we can see how it impacts our overall release scheduling.

We coordinate the inter-team work on the Epics through a number of avenues. We hold semi-weekly managers status meetings which reviews Project Central, and the latest release plan, in case we have any staffing or team productivity issues that need to be addressed (i.e. too much work given to a team, people on vacation, storm and form on other products that will take team members away from their current product release trains for a while, etc.). We hold semi-weekly Scrum of Scrums to keep team blockers managed. BTW: these manager and SoS meetings rarely take more than 15 minutes as we have developed a process for reporting using dashboards and Confluence to automate much of the work. We encourage teams to communicate frequently at their discretion regarding any issues they are having with their work - we just require them to keep the Scrum Master apprised.

Another SAFe principle we practice is that we run a corporate sprint cadence. All teams in every department sprint together, so when the PMO refers to Sprint 76 ending on such-and-such date - all teams related to the work going on in that release train know what this means. This helps us coordinate better across all departments to get release planning done from an end-to-end perspective.

I hope this novel of a response helps! If there is anything specific in this process I can explain better, please let me know.

nycjoker

Chris, thank you for the detailed reply! This is very helpful!

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