Configuring Self-Service Assignments

Before we start configuring Self-Service Assignments, let’s briefly talk about what happens under the hood when a user requests their next task by pushing the “Get next task” button either in User Console / Assignments or in a Jira Dashboard Widget.

Step #1

Task selection starts by identifying all work queues available to the user. If the “Default Queue” is enabled, it is available for all users to pull from. Any other queue

Step #2

In order to select the next most important task, Skills for Jira compares Top 1 tasks from each of the work queues available to the user using the following rules:

Higher priority tasks always go first
Given the same task priority, tasks from higher-priority queues go second
Given the same task priority and queue priority, the work queue is selected at random

Step #3

Skills for Jira will update the Assignee field to the current user

Step #4

The assigned task will be transitioned to one of the statuses specified in the queue configuration as “In Progress”

Work Queue configuration

Administrator needs to enable Self-Service Assignments and configure the work queues in Skills for Jira - Administration Console / Assignments:

Creating Work Queues

Skills for Jira ships with a “Default Queue” that applies for every user in Jira. Administrator can define any number of additional Queues to model assignment scenarios of any complexity. Queues can represent tasks of a specific Team, or Product, or Sprint, or any other scope of work.

The additional queues created by Administrator can be restricted to specific user groups:

Only users that are both in “marketers” and “trainees” groups will get tasks from “Marketing Training Queue”

Configuring Work Queues

Scope (JQL)

“Scope” is the most important part of queue configuration. It defines both the scope and the order of tasks in the queue.

Scope is defined in the form of a JQL query: you can select one of the existing filters or specify JQL directly on the configuration screen.

Scope MUST include ALL issues that belong to the queue. This includes both tasks that are waiting to be assigned as well as the ones that are already in progress

Tasks from the new queue will be fetched in the order defined by the scope’s “ORDER BY” clause

Local Priority

By default, when making the “which queue to pull from next” decision, Skills for Jira picks the issue with the highest priority, only reverting to queue priority (i.e. “1st pick”/”Last pick”) when issues are equal.

With Local Priority set, priorities of issues in this queue become irrelevant outside of the queue context. High priority tasks will not take precedence over tasks from other queues.

By enabling “Local Priority” on your queues you can ensure that issues from more important queues are delivered first, regardless of the priority of the tasks inside.

Figuring out how a queue with “Local priority” will interact with other queues can be challenging. Here a a few examples to help you assess fit for your use case:

1st pick queue with local priority and Standard task is preferred over
5th pick queue with local priority and Showstopper task
1st pick queue with global priority and Standard task is preferred over
5th pick queue with local priority and Showstopper task
5th pick queue with global priority and Showstopper task is preferred over
1st pick queue with global priority and Standard task
5th pick queue with global priority and Showstopper task is preferred over
1st pick queue with local priority and Standard task
1st pick queue with global priority and Showstopper task is preferred over
1st pick queue with local priority and Standard task
1st pick queue with global priority and Showstopper task is preferred over
1st pick queue with global priority and Standard task
1st pick queue with local priority and Showstopper task is preferred over
5th pick queue with global priority and Standard task
1st pick queue with local priority and Showstopper task is not preferred over
1st pick queue with local priority and Standard task
- JQL will determine the order within the same queue
- No rules will govern the order across queues

Statuses

You define how a task will be transitioned on assignment by selecting a set of FROM and TO statuses

Tasks in any of the “In queue” statuses represent the actual queue. They become available for fetching using the “Get next task” button.

When the task is fetched, it is transitioned into one of the “In progress” statuses for which the transition exists in the issue-specific workflow.

Qualification

Here you select one of the Skillset fields that specify skill requirements for tasks in the queue:

Tasks that include skill requirements that do not match the current user’s skill set do not appear in their work queues and are not available for pulling.

Pre-assigned user

Normally tasks can be pulled by any user that has the necessary skill set. Sometimes, however, you may want to pre-assign a task to a specific person.

While the recommended approach is to identify and document the skill or knowledge that makes this person the best candidate for the job, in order to be able to document or transfer it, in real work scenarios, it’s not always feasible.

You can use a separate field that will specify the preassigned user. This way, if the field is set, the task will only be available for pulling by this specific person.

Only User Picker (single user) fields can be used as “Pre-assigned user”

Dependencies

Very often a task can only be started after the ground work is done in previous tasks. Jira has a built-in concept of issue linking where you can define such dependencies as well as various other relations between tasks.

By indicating these dependencies in work queue configuration you will ensure that a task will not appear in the queue and will not be assigned until all dependencies are resolved.