Post List of Epics in Current Sprint with Data About Epic and Related Issues in Sprint

[Brandon Kidd]

Objective

Post a Slack message to display the list of epics in the current sprint, showing the key, summary, assignee, and priority, as well as the number of issues and story points in the current sprint for that epic.

Description

Below is what the Slack message I am wanting to post, where I would iterate over each epic in the current sprint and display the information for each.

As you can see, I need the following fields in the epics:

• key
• summary
• assignee.displayName
• priority.name

Here is the JQL that I am using for my lookup:

project = MyProjectNameHere AND type IN (Epic) AND sprint IN openSprints() ORDER BY rank

Note: It is important that I display the epics in their rank.

---

Next, I need to retrieve the sum of tickets and story points for each epic and ideally only hit the database once to keep the lookup performant. I planed to use the approach Bill helped me with previously and filter/match on the parent key. Again, here is the JQL I used in my lookup:

project = MyProjectNameHere AND type NOT IN (Epic, Initiative, Test) AND sprint IN openSprints()

What I've tried thus far...

I have tried capturing the list of epics in a variable.

{{#lookupIssues}}{{key}}///{{summary}}///{{assignee.displayName}}///{{priority.name}}{{^last}}|||{{/}{{/}}

I used some funky delimeters since the summary could have commas, pipes, slashes and the like, so it needed to be unique. My thinking was that I could split each epic by the three pipes ("|||") and then do string manipulation to get the key, summary, assignee, and priority for each. Alas, I couldn't figure out how to manipulate {{.}} to work for me.

Defeated, but not willing to give up, I decided I would just convert my list of epics into a JSON and then use dot notation to get the values. It turns out that isn't something built into automation (from what I can tell).

---

Do you all have any ideas of what I could try or can point me in the right direction? Any help is greatly appreciated!

[Bill Sheboy · Accepted solution]

Hi @Brandon Kidd 

Short answer: do you want one Slack message per Epic?  If so, this is possible by branching over the found-parent Epics, and then using Lookup Issues to gather their child issues' data.

However, if you want one single message for all of the Epics, I do not believe this can be done with one rule.

I hypothesize your child Story, Task, etc. issues are the ones added to the Sprint, and so when they have an associated Epic, it is accessed via the "parent" field (not the Sprint).  Thus if the rule was triggered on Sprint Started, it could find the child issues and then later the parent Epics.  However...

Neither JQL nor automation features have the concept of "group by" (e.g., group by the Epic parent), so I do not see how a single rule could find the Epics, loop over them to gather their child data, and then send one Slack message.  And there is no sequential branch processing in rules to support rolling up the data for later use in the same rule.

What could be tried is one rule triggered on Sprint Started to find associated issues' Epics, loop over the associated Epics to gather / sum their children's data, and store that somewhere in the Epics (e.g., custom fields).  A second rule could then gather the Epics' data and send the message. 

Another challenge would be: when should the second rule be triggered?  Theoretically it could be scheduled and use checks on the rollup fields to know when to "go", but this is all getting a bit complicated for a reporting / alerting scenario.

Kind regards,
Bill

[Brandon Kidd]

:sad-panda: It would be nice if I didn't have to break it up into separate rules, but your feedback put me on the right track, @Bill Sheboy

Some background... we have automation to move epics into the active sprint if their child issues are in the sprint. From there we utilize the Jira List app filtered to only show epics in the openSprints(); this page makes it easy to edit inline and move epics in stacking rank based on business needs. With that, I decided to create two rules:

Rule 1:

1. Triggered when a new sprint is created (and delayed by 5 minutes to give our other automation time to do its magic).
2. Grab the list of epics in the sprint using a lookup:

   project = MyProjectNameHere AND type IN (Epic) AND sprint IN openSprints() ORDER BY rank

3. Verify my lookup has issues with an if statement checking {{lookupIssues.size}} is greater than 0.
4. Advanced branch on {{lookupIssues}}, setting the variable for each iteration as {{varEpic}}
5. Perform my lookup for issues with the parent equal to {{varEpic.key}}:

   project = MyProjectNameHere AND sprint IN openSprints() AND parent = {{varEpic.key}}

6. Now here is where I do the magic... I use a web request to PUT a property named sprintIssues with the data I need to access later:

   https://sub-domain.atlassian.net/rest/api/3/issue/{{varEpic.key}}/properties/sprintIssue

   passing in my custom data as follows:
   

   {
     "count": "{{lookupIssues.size|0}}",
     "points": "{{lookupIssues.Story Points.sum|0}}"
   }

7. All of the data for iterating through the epics in my sprint are now available in my now much simpler rule.

Rule 2:

1. Triggered when a new sprint is created (and delayed by 10 minutes to ensure all of the magic is done and the epics have been updated).
2. Grab my list of epics just as I did in the first rule.

   project = MyProjectNameHere AND type IN (Epic) AND sprint IN openSprints() ORDER BY rank

3. Call my web request to Slack using my webhook URL doing a POST of my custom data with the information:

   {
     "blocks": [
   {{#lookupIssues}}
       {
         "type": "section",
         "text": {
           "type": "mrkdwn",
           "text": "*<https://sub-domain.atlassian.net/browse/{{key}}|{{key}}>* {{summary}}"
         }
       },
       {
         "type": "context",
         "elements": [
           {
             "type": "mrkdwn",
             "text": "*Assignee:* {{assignee.displayName}} | *Priority:* {{priority.name}}: | *Tickets:* {{properties.sprintIssues.count}} | *Points:* {{properties.sprintIssues.points}}"
           }
         ]
       }{{^last}},{{/last}}
   {{/}}
     ]
   }

4. Voila!

Rule 1 takes ~40s to execute and rule 2 ~5s. Not too bad on performance and we get all of the data we need to share with business leaders when the sprint starts.

Going to mark your answer as accepted so others can hopefully use this approach and learn from my Bill Sheboy-encouraged approach. Thank you!

[Bill Sheboy]

Well done, and two things for your rules:

There is a Set Entity Property action which could be used for rule #1 without directly calling the REST API endpoint.

Your rules rely upon execution timing for when rule #2 expects things are ready for processing:

• If you are using the new Delay action in your rules, I recommend caution and observation to confirm it works as documented.  I hypothesize there will be changes the provided-behavior over time.
• When the next automation outage (or engine slow down happens), please confirm your rules ran as expected.  My suggestion is based upon posts from Atlassian staff indicating when issue, project, sprint, scheduled, etc. event-triggered rules should have occurred and there was an outage, in the best case the timing will be disrupted.  For scheduled trigger rules, it is unclear if the missed schedules will run at all.