Sorry, we don't support your browser.  Install a modern browser

Add a "Group By" function to display issues in a Sprint#4

The ability to show only issues in a sprint underneath an epic, so that users can track Epic progress and Sprint progress based on the issues in the sprint.

Current workaround requires users to create a filter that contains issues in a defined sprint, then diplay it on Hierarchy for Jira.

a year ago
Changed the status to
Gathering Interest
a year ago
P

This is one of the ideas I intended to post here. Yes, this would be useful!

4 months ago
P

The workaround described above is not that useful though because we lose context with the set tree structures that hold, in my case, various levels of Epics. I use a filter with something like (parentEpic in KEY-123, KEY-456, etc). If I wanted to filter this view with only those issues in sprints I would define this filter but I will lose the epics that form parts of the tree that provide context and it becomes a flat list of issues that are not very useful alone. It would be ideal if I could apply a filter to this view that will display the issues where sprint in opensprints() or sprint in futuresprints(), preserving the layers of the tree in between. Basically, filter out those issues that are not in open or future sprints but show the tree structure for everything else by honoring the links that exist as parentOf or childOf.

For example, refer to the attachment. Let’s say this data shown represents my filter applied to this tool. These two issues with red arrows are the only two issues in an open or future sprint. It would be great to have a filter button (issues in open/future sprint) on this page that will cause the issues shown highlighted yellow to display while hiding everything else. In this case, I will have the contextual view required to make business decisions.

Of course, I could piece together, with tons of my time, a filter that includes the epics I want to display while including those issues of a certain issue type that are in an open sprint or future sprint but that requries a lot of man handling of various filters to maintain continuity. I’d have to named keys in the filter and then have logic to get issues of a certain type that are in a sprint. My list of these named keys will change over time so maintaining the set of filters would be tediuos work. ;)

3 months ago
P

…basically, I’d have to maintain a filter like this and alter the set of named keys as things evolve.

key in (TST-789, TST-098, GNO-324) or (issueType in (Task) and parentEpic in (TST-789, TST-098, GNO-324) and (sprint in opensprints() or sprint in futuresprints())

3 months ago