Block the option to work on tasks not on the sprint

[Yael Dvorin]

Hey,

We are experiencing some cases of R&D people not paying attention to whether a task is on the current sprint or in our backlog, and start working on it.

I'd like to create a condition that if the task is not on the active sprint, I won't be able to change the status from Ready for Dev to Dev in progress.

Any ideas how to do it?

Thanks!

[Oliver Siebenmarck _Polymetis Apps_]

Hi Yael,

While I very much believe that Jack is on to something, I can also see situations where you'd still want to enforce a rule. It could be that team members accidentally pick the wrong task, simply because they are unaware or anything else. Whatever the reason: yes it is possible to have such a condition on Jira Cloud.

However, you will need an App that supports custom conditions with Jira Expressions. Fortunately, you have a few to choose from. My personal favorite is Cloud Workflows which comes with a condition template for "Issue must be in current sprint".

In any case, this is the Jira Expression you will need to use:

issue.sprint.state == 'active'

Hope that helps,

 Oliver

Full disclosure: I work for Jodocus, the Vendor who created Cloud Workflows. Let me know if you need any help getting started, I'm be happy to help!

[Jack Brickey]

I don’t think this is an issue to solve in Jira. This seems to be an issue with building a team based upon trust and focus on common goals. Taking this approach results in all members of the team working together which yields the best results. If this is wide spread then it’s time for some team building. If it is one or two individuals then a private conversation might be best. Are the R&D members part of the sprint planning and daily stand ups? That is critical to drive buy in and a feeling of being part of the team. Finally simply blocking an issue from being transitioned would not block an engineer from writing the code and submitting.

With that editorial out of the way. If you still wish to proceed down your path I would suggest creating a separate project where the first (vetting)  would feed the second (approved) and limit members on the first. Of course this supports an environment based upon walls which is not a great environment, IMO. I prefer one team, common goals, trust, etc.