You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I'm sure there are several ways of doing this, however since I recently crossed on questions regarding this topic, I figured I might as well share it in details :).
For starters, I work in a bank, IT Division, Software Development Department. Also I'm the guy in charge for Jira and Confluence dev & app administration.
In our department, being developers, we don't have that many recurring tasks. Sure there are recurring actions, meetings, but tasks... no. On the other hand colleagues from the IT Operations department tell a different story. They have daily maintenance checks and procedures to execute. This was becoming an overhead, as they still needed to keep a manual "checklist" for the order of tasks and also open a new Jira issue each day (we don't keep issues open to log on repetitively).
We needed something automated, but also configurable. Meaning that this should not be a hard-coded template which would require tinkering to change.
This was one of the cases where I didn't do much research ahead.
Not necessarily a bad thing, since the solution seemed pretty obvious based on our current setup.
We clone issues a lot in our Jira and have this is "automated" in the workflow, which saves a bit of time. So essentially cloning a "template" would work for this one.
Benefits of this approach are that templates will always be available to reconfigure easily, disable/enable in case of need and they will not be hard coded, which would always require a developer available to change the template.
We already had these add-ons in place, so that's the reason why I leveraged on them.
Upon creation, each issue will be automatically marked with a label, "recurring-task". This will help to easily identify these kind of issues.
is the same as Target Project Task Screen. This will make sure that the fields are always consistent.
Checklist can either be left empty and configured later, or configured directly from the Create Screen.
User can enter all the tasks for that issue. Checklist items can be Mandatory or not (mandatory blocks resolving unless checked).
Using Built In Groovy Scripts from Adaptavist Script Runner, an Escalation Service was created, which triggers the "Recurr" transition for the selected issues.
This transition will clone the issues in Target project.
Issues are filtered using JQL:
Additional actions required are setting the reporter as our "Robot" use instead of original issue reporter and set the issue as Unassigned:
newReporter = ComponentAccessor.getUserManager().getUserByKey(
issue.reporter = newReporter
Since all issues have a predefined label, they can be easily filtered.
In our main "Target Board" a quick filter will be added, "Recurring Tasks". If used in combination with "My Business Services" it will produce the output of "My Recurring Tasks" (optional quick filter).
My Business Services - this is something we use to differentiate between the applications each user is responsible for. We used Insight to do this and it allows all of us to have a single view. Will talk more in depth about this in another article and link it here.
Also users can create their own boards if they choose to do so as normally. JQL can be used for simple board:
Or they can customize it only to their Business Services:
This is the view of the actual recurring/daily task. Additional checklist items can be added if needed.
After picking up the issue from Backlog, assignee can use the checklist and tick each item after completion to keep track of their work.
Overall this was a simple setup, as our requirements were simple enough (i.e only 1 frequency of creation), but I like the approach and I think it could scale for further usages.
Any tips for improvements are welcomed, also questions.
Gezim Shehu [Communardo]
42 accepted answers