Jira Automation: How to include story points in sprint when issues 'done' at sprint closing?

anthony_laforgia

My team has some items that are considered 'Business As Usual'. They reoccur every sprint. 

Currently, I have an automation in place that creates and closes these issues when a new sprint is opened or closed, respectively. This is done with labels (i.e. if the issue has a certain label when the sprint is closed, the issue is marked as 'Done'). 

The problem is with the reporting/story points. Since the trigger is the sprint closing, the issue is considered 'incomplete' when the sprint closes; the issues are marked done a few seconds later. The story points don't get deducted in the charts as well.

Is there a way/trigger to close the issue at the sprint closing, so the issue is 'Done' within the sprint? Something other than a scheduled trigger (like every two weeks, close the labelled issues) is desired. 

thank you! 

 

 

Walter Buggenhout

Hi @anthony_laforgia,

Before going into a possible workaround, may I take the liberty to challenge a couple of things in your process:

• Consider not estimating your business as usual issues. In a scrum process, story points are meant to measure the items your deliver adding value to the product you are building. Business as usual, by definition, is not part of that added value delivery. You may even want to consider leaving these activities out of the sprint, but that may of course mean you don't see them anymore. Hence, not adding story points to them would solve your reporting issue;
• The idea of issues on a board is that they are done by your team members. They should take care of the work, manage its status throughout the workflow and close issues when they are done. It would be fair to assume that open issues at the end of the sprint are actually not done.
• Building on that previous point: consider why your are closing items automatically when they are not marked as done by your users? Doing so basically relieves your team members from their responsibility to do these tasks and you will not be able to verify whether the work was actually done or not in reality.

If you still want to automate the process, you seem to have all the logic in place to reduce the manual work of creating new issues. I would suggest to split the automation rule, so that you can (scheduled or from a manual trigger) close the issues separately before you close the sprint and create the new issues.

Hope this helps!