Scrum
This workflow includes several rules that support the scrum framework for agile product development.
| File Name | jetbrains-youtrack-scrum |
|---|---|
| Auto-attached | yes |
| Rules | Assign on move (stateless) Epics can not have ideal days (stateless) Fix parent task when all subtasks are resolved (stateless) Open parent task on any subtask open (stateless) Tasks can not have story points (stateless) |
Use Case
This workflow helps you automate and manage issues when you use a scrum framework for agile product development. The rules in this workflow help you manage assignees, ideal days, story points, subtasks, and sprints.
Rules
This workflow includes seven different rules.
Assign on move
When the state of a reported issue is changed and not assigned, the Assignee is set to the currently logged-in user. This rule automatically assigns an issue to the user who moves a card, for example, from an Open state to the In Progress column on a scrum board.
rule Assign on move
when issue.isReported() && issue.Assignee == null && State.changed {
issue.Assignee = loggedInUser;
}Epics can not have ideal days
This rule prevents users from setting ideal days for epics. Epics represent large features that contain multiple user stories and are usually delivered over a set of sprints. Ideal days are usually set for the tasks and not for epics.
When an user changes the value that is set for the Ideal days field for an issue that is assigned the Epic issue type, this rule checks the new value set for this field. If the Ideal days field is set to anything other than zero or empty, a warning is displayed. The change is rolled back to the previous value.
rule Epics can not have ideal days
when issue.Type == {Epic} && issue.Ideal days.changed {
assert issue.Ideal days == null || issue.Ideal days == 0: l10n ( Epics can not have ideal days );
}Fix parent task when all subtasks are resolved
This rule helps you manage the state of issues with subtasks (parent tasks). The rule automatically changes the state of a parent task when all subtasks are resolved.
When a reported issue is set to a resolved state, this rule checks the issue for parent tasks. If the issue is a subtask of a parent task, the rule checks the status of all other issues that are linked as subtasks to the parent issue. If all subtasks are set to a resolved state, the state of the parent task is set to Done. A notification is displayed.
The rule then performs the same operation if the parent task is a subtask of another issue.
rule Fix parent task when all subtasks are resolved
when issue.isReported() && issue.becomesResolved() && issue.subtask of.isNotEmpty {
var parent = issue.subtask of.first;
while (parent != null && !parent.isResolved()){
var allSubtasksResolved = true;
for each subtask in parent.parent for {
//We can't use subtask.isResolved() here, as this method relies on issue.resolved
//property, which is updated after workflow rules are executed.
if (!subtask.State.isResolved) {
allSubtasksResolved = false;
break;
}
}
if (allSubtasksResolved) {
parent.State = {Done};
message(l10n ( Automatically set{parent.getId()} as Done));
}
//NPE-safe operation: if we can, we take the next ancestor and try to close it too
parent = parent.subtask of.first;
}
}Open parent task on any subtask open
This rule helps you manage the state of issues with subtasks (parent tasks). The rule automatically re-opens a parent task when a subtask is set to an unresolved state.
When a reported issue is set to an unresolved state, this rule checks the issue for parent tasks. If the rule finds a parent task that does not belong to an archived project and is set to a resolved state, the state of the parent task is set to Open. A notification is displayed.
The rule then performs the same operation if the parent task is a subtask of another issue.
rule Open parent task on any subtask open
when issue.becomesUnresolved() && issue.subtask of.isNotEmpty {
var parent = issue.subtask of.first;
while (parent != null && !(parent.project.isArchived()) && parent.isResolved()) {
parent.State = {Open};
if (parent.Type != null) {
message(l10n ( Automatically reopen {parent.Type} {parent.getId()} ));
} else {
message(l10n ( Automatically reopen {parent.getId()} ));
}
//NPE-safe operation: if we can, we take the next ancestor and reopen it too
parent = parent.subtask of.first;
}
}Tasks can not have story points
This rule prevents users from setting story points for tasks. Story points are an arbitrary measure used by scrum teams to estimate the effort required to implement a user story. Story points are usually set for the user stories and not for tasks.
When an user changes the value that is set for the Story points field for an issue that is assigned the Task issue type, this rule checks the new value set for this field. If the Story points field is set to anything other than zero or empty, a warning is displayed. The change is rolled back to the previous value.
rule Tasks can not have story points
when issue.Type == {Task} && issue.Story points.changed {
assert issue.Story points == null || issue.Story points == 0: l10n ( Tasks can not have story points );
}