JIRA Practices

This document describes the  in more detail. See the guide for writing tickets in JIRA for general instructions.

Responsibility for work: The Assignee

The Assignee of the task / bug is responsible for looking after the status of the issue. Ideally he can do something about it himself, but it is not always possible to complete the work without help.

• If a task needs further action from someone else in order to be completed, a subtask or new task with a suitable relation link should be created and assigned to the responsible person. For instance, if you need two other people to test a new feature before you can close an issue, create two subtasks and assign them to the people responsible for testing. This way, you can monitor on your own board if the work has been done.
• If comments are required from a colleague, you can mention the recipient’s @username accordingly in the  Comments section (or even within the Description).
• You should avoid adding other people as Watchers of the issue! (This is because each watcher receives a lot of unnecessary notification emails every time someone edits tiny details in the issue, and so they might start to consider all Jira emails as spam.)

Priority vs. Issue type

Note that the priorities do not correspond with the complexity of the issue. (A blocker can be a complex file system issue or a tiny little execute permission problem that is fixed with a chmod.)

Instead, issue complexity is indicated by issue type.

Type

• Epic: A complex set of Stories or tasks, eg. Publish a corpus or Certify Kielipankki according to ISO 27001.
• Story: A complex ”task” that takes more than a day to complete and can be split into tasks.
• Task: A ”task” that takes less than a day and cannot be subdivided.  (i.e. write an email, or move something to Github).
• Bug and New feature / Improvement speak for themselves. They distinguish expected or desired behaviour in software.

When unsure, use Story as default.

Priority

Possible values, in order of importance:

• not prioritized
• Blocker
• Critical
• Major
• Minor
• FYI (For your information)

To use the fields consistently we need to agree on their meaning. The meanings should be similar for each Type: New Feature, Bugs, Tasks, Stories and Epics.

FYI: Nice to have, but not essential. No one needs to do anything. We close or reprioritize them twice a year.

Minor:  Minor issues need attention, but not in the near term. Setting a Due date for minor issues is recommended. They usually become more important if not addressed for a long time.

Major: Issue should be addressed within ~3 months. Set the Due date accordingly.

Critical: Issue should be addressed within 1-2 weeks. Set the Due date accordingly.

Blocker: Issue that prevents someone (a colleague or customer) from progressing. E.g., a bug that prevents a service from working, a missing feature that prevents the roll-out of a service or corpus. Needs attention within 3 days. Set the Due date accordingly.

Not prioritized: The default. Having an issue in this state for a long time is a problem, since the Assignee does not generally get any encouraging signals to complete the task. However, ”not prioritized” usually shows up highest in priority-based rankings, reminding people to at least set the priority.

Workflow management

Jira support the idea of a workflow to give issues a life cycle. The states of an issue are described below. We do not yet have fixed practives for all transitions, the information below is intended as a suggestion.

Open

All new issues first end up here. Open issues are the big pool of issues that constitute a ”Backlog” in Kanban/Scrum terminology.

Selected for Development

Issues that should soon be addressed. Ideally you should first pick from here before picking from ”Open”.

In Progress

Again: Ideally: What you work on this week.

Waiting for Others

Issues that cannot proceed because you wait for some one else to do something.

In Review

Completed issues that require a review. Unless super trivial all issues benefit from a review, and be it that the reviewer is made aware that something is fixed.

At CSC we decided to use labels to assign reviews, since most reviews are non-urgent and labels allow for easy finding of reviable issues. Urgent reviews are either requested directly or via a sub task (”Please Review”). We also decided to have a permanent item on the agenda of our regular status meetings to remind each other of requesting/completing reviews.

Closed (Done)

Issues are ready to ”Release”, i.e. finally declared done. Project Administrators are able to release.