Best Approach for restricting scope of a plan around an initiative while still seeing sprint info

[Mike Villis]

I'm curious to get the community's input on ways they have approach this use case in Advanced Roadmaps.

We have `Initiatives` which are collections of Epics from one or many projects in Jira. 

When a Program manager sets out their plan they use the `portfolioChildIssuesOf` function as a Filter Issue Source for all of the scope they are interested in viewing/planning. It will automatically gather up all the relevant issues based on parent links. In most cases this is a narrow sub-set of issues from a series of projects.

The problem with this approach is it doesn't show any Sprint planning details for any stories. To show this you must add additional Boards/Projects issue sources to the plan for any of the projects in scope of the program.

This works however there is a side effect that additional cards not relevant to the particular PMs work start appearing on the board. These issues can be removed from the plan but this continues to be a manual tasks as more and more issues are added.

For now I've just learnt to ignore any `Issues without parent` though for some larger plans this becomes a performance/noise obstacle.

Does anyone else have this problem? What is the best Approach for restricting the scope of a plan around a point in the issue hierarchy while still seeing sprint info?

[Dave]

Hey @Mike Villis ,

This is an interesting use case and as well as providing a couple of suggestions, I just wanted to provide some context around what is happening here.

At the present time only the active sprint has dates associated with it. In Advanced Roadmaps all the other sprints are drawn on the timeline using the sprint order from the board and the sprint iteration length configured for the team associated with the board.

This is why sprints are only loaded when a board issue source is used. Without a board and the active sprint it would not be possible to know where to draw non-active sprints on the timeline.

If you wanted to exclude issues from a plan then there are a couple of (similar) options but they do require applying metadata to issues.

One option might be to lean on Releases and assign the issues within the hierarchy to a specific Release or Releases. When you configure the issue source you could select just the releases that you're interested in.... the obvious downsides to this are that you have to ensure all the issues you're interested in are assigned to those releases and it wouldn't ignore issues not assigned to a release.

A similar option would be to add some other metadata to the issues (component, label, custom field, etc) and include that metadata in the JQL filter, then use that filter as the the source of a board and then use that board as the issue source to the plan.

The advantage of this is that you'd have a single issue source for the plan, the disadvantage would again be that you need to ensure that you add the metadata to all the issues. It might be possible to do this through some automation, but I'm not sure.

Also, if you were going to use metadata in this way it would actually be more efficient to create a filter from using the portfolioChildIssuesOf function and bulk apply the metadata to the results but use a different filter (keyed of the metadata) as the issue source. The reason for this is that they portfolioChildIssuesOf function is relatively slow compared with other filters so your plan would load faster. The disadvantage is that you might not be able to guarantee that only the issues you're interested in have that metadata applied.

Maybe some others in the community have alternative suggestions, but those are the best I could think of at the present time.

Regards,

Dave

[Mike Villis]

Thanks Dave for taking the time to think about this scenario. Great feedback - similar to what I've been pondering. At least for now the extra management of the meta-data doesn't seem to be worth it. It would be duplicating was is there with Parent Link but without the useful hierarchy. Seems to be one of those things I can just put up with until there are other options in the product.

eg. Easily be able to select all issues without a parent link (for easy removal from the plan).

OR the ability to infer sprints for Filter data sources without pulling in the entire board contents.

[Dave]

No worries, one quick observation...

Easily be able to select all issues without a parent link (for easy removal from the plan).

I think you can currently achieve this using the issues without parent section of the interface.

If you have your hierarchy filter set from Initiative -> Epic (or lower) then the "Issues without parent" section (underneath the main list of issues) will show you all those without a parent (or at least without a parent that exists in the plan).

You can then select all of those issues (there's a hidden "Shift Click" option for selecting a lot of issues easily) and then you can remove them from the plan.

Regards,

Dave

[Mike Villis]

Nice Dave! Did not know about the shift click capability. That is very very helpful! Happy Monday :-)

[Aaron Gage]

This is EXACTLY the same use case I've been struggling with!  I've been reluctantly pulling in all the boards (can be alot and fluctuate....) and deselecting all of the issues with out parents in the scope screen.  Though while doing that, I still see some issues squeeze by for some reason that I can't for the life of me figure out....  Ideas?

In fact the current example pulls in an Epic that is not listed on the scope screen at all.....Granted the Epic is listed on the scrum board.... has me much perplexed.

Would love for the tool to just be able to tie the Shared Team to a board and have it pull in their sprint dates without loading the whole board as an issue source.  (Today you can't tie a shared team to a board without selecting it as an issue source)

Love to see there is actual feedback Dave!  And that I'm not crazy in my struggles :)

[Kaushal Patel]

i am having a similar issue. when i did the filter route and created a new board. Jira advance plan now adding the sprint with ext, but when i go to the board it has the sprints there. 

https://support.atlassian.com/jira-software-cloud/docs/what-are-external-sprints-in-advanced-roadmaps/

It also says not 
To avoid creating external sprints, we recommend that you use boards as issue sources where possible as sprints are conceptually tied to boards. Issues imported from projects and filters may comprise multiple boards (and therefore sprints) which will show on your timeline as external sprints.

Did anyone find a solution for this?

[Aaron Gage]

I have not....other than pushing my organization to invest in Structure.gantt which looks to be far more mature than AR.

[Crystelle S]

This is an older one but in case it comes up in a search I will say that I have something similar in my Plans with scriptrunner

issuefunction in portfoliochildrenof()

What we did to get around it is create a "silent" board that pulls the same issues that the filter does. Jira will show the sprint information on the ticket regardless of what board you are pulling. This does mean you may "lose" the future sprints if one of your tickets isn't already in it, however at an org as big as ours, there was no "perfect" way to do this. Because the sprint information remains attached to the ticket, the board that I created pulls other board information inside of Jira before coming to Plan. It helps decrease the processing load.