Ranking (tasks) by "parent" project (epics) order

[Jussi Juvonen]

Hello,

Our setup is following:

We have own project and board (kanban) for epics, lets call this epicsOnly project. To each epic we add number of tasks that belong to various other projects which all have their own boards (kanban), lets call one of these tasksOnly project.

Now when tickets are moved to certain column and certain ranking (top to bottom) in the epicsOnly project, we would like this order be also automatically reflected to the tasksOnly project. The order of individual tickets does not matter as much as just having that bundle of tickets change when ever the rank of the parenting epic changes.

We do have script runner, which presumably could help with the job, but little experience on how to use it efficiently. Basically the board swim-line JQL could be something like:

project = tasksOnly AND issueFunction in issuesInEpics("project = epicsOnly AND type = epic AND status = 'In Progress'") 

That already gives all the epicsOnly issues nicely to a single swim-line, just the ranking is something we need to still do manually.

Then (imaginary part):

ORDER BY epicsOnly RANK

Any ideas?

[Mike Joyce]

We set up BigPicture and struggled with similar condition, but wanted to focus on higher level view: Initiatives, Projects and Epics only.   But only wanted to present Medium and High priority Projects in BigPicture.  So we needed up with this:

issueFunction in linkedIssuesOfAllrecursivelimited("issuekey in (KEY-001, KEY-002, KEY-003, KEY-004, KEY-005)", 2) AND status not in (Complete, Done, "Program Complete") AND issueFunction in hasLinkType("Parent/Child") AND (issueFunction in linkedIssuesOf("issuetype = project and priority in (Blocker, High, Medium)") OR (issuetype = Project AND priority in (Blocker, High, Medium)))

Fundamental thing to realize is filters reduce results pool. Meaning you cannot bring in more results as you work your way through the JQL. So this starts out pulling in all linked issues to specific keys (we use issueType Initiative as parent keys). From there we only wanted items not 'done'. Then, issues which have a link of Parent/Child (this is the type of link between Initiatives and Projects and Epics). Now for the tough part - we want all Epics (any priority) linked only to Blocker/High/Medium priorty Projects

issueFunction in linkedIssuesOf("issuetype = project and priority in (Blocker, High, Medium)") 

[that only pulls in the Epics]

as well as the Projects

(issuetype = Project AND priority in (Blocker, High, Medium)))

BigPicture stitches results together in nice linked view.   Good luck and hope this helps 

[francis]

Hi Jussi,

We have a similar setup. Epics are tracked in a specific projects, and broken down into product related projects (which track the versions)

We also have 2 boards 

* An epic board with an epic specific workflow for the project management aspects

(Assess, Prepare, Plan, In Progress, Validate, Done)

* A scrum board which is used by the engineering team for the daily follow-up.

The query of the scrum board is pretty advanced

   filter = "ADDON Epics - in work" 
OR filter = "ADDON - spike epics" 
OR filter = "ADDON Epic stories - in work" 
OR filter = "ADDON - Epic Spike" 
OR filter = "ADDON - issues without epics - all - take2" 
OR filter = "ADDON Waiting for support" 
ORDER BY Rank ASC

This query ensures  that the scrum board contains only the epics and stories which are 'in progress' or epics which have a spike associated to it, or issues which are assigned to the sprint.

Once that we decide that the epic is fully prepared (knowing what we are going to implement and how it should be done), we advance the epic to 'in progress'.  From that moment the epic shows on the scrum board (in the backlog)  

Just a long intro to tell that changing the priority of an epic is immediately reflected on the scrum board in the backlog and in the active sprint view.

The order by rank asc in the query above is doing the magic.

[Jussi Juvonen]

Thanks Francis,

Indeed it seems you have something very similar!

Still having a bit trouble understanding how this would solve the ranking of tasks by parent. Regardless of what your filters return, they are just bunch of tasks (or equivalent) on your scrum board. Your OR-structure would be somewhat analogous as doing UNION on a relational database, right. But how wouldn't the Rank still be the rank of the tasks that you get with the filters rather than the parent rank? Probably missing something trivial here? :)

I have one route in my mind that should theoretically work. That would be to update a custom field on all child tasks on relevant events happening on the parent. Suppose I could use the lexorank of the parent here. Though I really wouldn't want to take this route as it does not seem at all trivial, but rather something very hacky.