Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?

2 comments

Dave Atlassian Team Feb 01, 2021

Hey @Michael 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

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.

Like Dave likes this
Dave Atlassian Team Feb 07, 2021

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

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

Like Dave likes this

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

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira

⏰ Day in the life of a Jira Admin!

Hello Community! We thoroughly enjoyed this just-for-fun conversation in the Jira Admin Group about what it's like to be a Jira Admin. For #JiraJuly, our talented designers created these graphics t...

49 views 0 6
Read article

Community Events

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

Events near you