Jira

Jira is a very important tool at VSHN. We track everything in Jira, including internal events, trainings, meetings and many other things. Getting used to how Jira works is a very important part of your daily life as a VSHNeer.

Our Jira is available from ticket.vshn.net.

Project and Taskplanning

We use issue linking to link task and project management together ("blocks" and "blocked by"):

Each customer gets a Jira project called "Customer: NAME," with an ID that’s composed of three or four characters, easily associated to the name.
- Project Lead: Customer Account Manager (CAM)
In a Customer Jira Project, there is at least one issue of type "Operations."
This is used for ongoing operations and customer requests, which aren’t tied to a specific project.
A Customer Project is planned in the issue type "Project." There is a "Customer Project" template available, which adds a boilerplate with all information and questions needed.
Real work gets done in "Task" or "Chore" issue types.

If you use Firefox you can add the Jira search engine to your "One-Click Search Engines" list by clicking the … button on the location bar. Then, in about:preferences#search you can assign a keyword to it, for faster searches.

Issue Types for Project Management

A Jira Project (aka Customer) can have one or more "Project"
A Project can have zero or more "Project Milestone" (it really only makes sense to use milestones if there is more than one milestone) and zero or more "Task" and "Chore"
A Project Milestone can have one ore more "Task"
A Operations can have one or more "Task" and "Chore"

Issue Type	Usage	Roles
	The container holding different issue types together. Also contains the overall definition of the scope, stakeholders, etc. When a project has no milestones, this is the flight level on which we plan "VSHN wide" projects and timeline planning	Reporter: The main stakeholder Assignee: Project Manager
	A milestone is a specific point in time within a project lifecycle, used as signal posts for: a project’s start or end date, a need for external review or input, a need for budget checks, submission of a major deliverable, etc. Milestones have a fixed (due) date.	Reporter: The main stakeholder Assignee: Project Manager
	Used to group different categories of work or services on the customer side; not used in project management.	Reporter: Service Manager Assignee: Service Manager or Technical Service Manager

Issue Type

Usage

Roles

jira project

The container holding different issue types together. Also contains the overall definition of the scope, stakeholders, etc.

When a project has no milestones, this is the flight level on which we plan "VSHN wide" projects and timeline planning

Reporter: The main stakeholder
Assignee: Project Manager

jira project milestone

A milestone is a specific point in time within a project lifecycle, used as signal posts for: a project’s start or end date, a need for external review or input, a need for budget checks, submission of a major deliverable, etc. Milestones have a fixed (due) date.

Reporter: The main stakeholder
Assignee: Project Manager

jira operations

Used to group different categories of work or services on the customer side; not used in project management.

Reporter: Service Manager
Assignee: Service Manager or Technical Service Manager

Issue Types for Task Management

A Task or a Chore must block exactly one Project Milestone, a Project or an Operation.

Issue Type	Usage	Roles
	A request from a customer. Will be triaged (assessed and assigned) by the ticket Triage Process.	Reporter: Customer Assignee: None
	Tasks, of a Project, a Milestone, or Operations. This is where the actual work is done.	Reporter: undefined, usually the creator Assignee: VSHNeer working or planning to work on this issue
	A recurring task (like meetings, project management, daily operations, etc.)	Reporter: Project Manager or Service Manager Assignee: Responsible person

Issue Type

Usage

Roles

jira request

A request from a customer. Will be triaged (assessed and assigned) by the ticket Triage Process.

Reporter: Customer
Assignee: None

jira task

Tasks, of a Project, a Milestone, or Operations. This is where the actual work is done.

Reporter: undefined, usually the creator
Assignee: VSHNeer working or planning to work on this issue

jira chore

A recurring task (like meetings, project management, daily operations, etc.)

Reporter: Project Manager or Service Manager
Assignee: Responsible person

If you encounter an error in one of VSHN’s own services (Mail, GitLab, etc.) please don’t open a ticket in the VT space, but rather in the VSHNOPS space, and don’t forget to use the corresponding template. This helps the corresponding team (usually Polaris) to solve the issue faster and better.

Issue Blocking Rules

Different issue types can only block other specific issue types. The following diagram shows who can block whom.

Jira Workflow

This workflow applies mainly to technical tickets and tickets from tech teams. Other areas like Recruiting, Backoffice, etc. might have other workflows.

Task states

In use by the following issue types: Task, Request.

State	Meaning	Notes
New	Needs to be triaged by 1st Ops.
Backlog	Kanban Backlog, will be refined by the "Backlog refinement" in Teams and Interest Groups and then selected by Teams. Usually not urgent tasks start in the Backlog.
Selected	Chosen by a Team to work on next, Urgent tasks (for example, Incidents and changes) may also go directly to Selected.
In Progress	Is currently worked on by Assignee
Waiting	Already worked on the task but currently on hold, for example, Engineer has to stop working because of a more urgent issue, or ticket was automatically transitions from "Waiting for Customer" or "Waiting for Third Party" and the engineer will work on this again soon.
Waiting for Third Party	More specific than waiting, that means a third party like upstream or support is blocking the continuation	This state doesn’t include waiting on the customer
Waiting for Customer	We can’t work on this task as we the customer needs to do something first (test, give feedback, answer a question) but the task isn’t considered done from our side yet.
Waiting for Internal Feedback	Task isn’t finished but waits for a VSHN internal feedback before it can be continued (code review, …)	Do not change the assignee, but mention the one you’re waiting for
Waiting for Maintenance	Everything is prepared and the next step in the task needs to be done during a planned maintenance window (for example, weekly maintenance window).
Missing Information	The issue needs more information before it can be triaged or the ticket quality is in an unusable state. Mostly used during triage by 1st Ops.
Internal Review	The issue is done (all task deliverables completed) and should be reviewed by a work mate before closing.	Change assignee to reviewer
Customer Review	The issue is finished (all task deliverables completed, internal review done where feasible) and the customer informed, waiting for customers feedback.	When no feedback from customer, close issue after 1 week
Done	Finished. Nothing can be done anymore on this issue. If something pops up after putting an issue in the Done state, a new issue needs to be created

State

Meaning

Notes

New

Needs to be triaged by 1st Ops.

Backlog

Kanban Backlog, will be refined by the "Backlog refinement" in Teams and Interest Groups and then selected by Teams. Usually not urgent tasks start in the Backlog.

Selected

Chosen by a Team to work on next, Urgent tasks (for example, Incidents and changes) may also go directly to Selected.

In Progress

Is currently worked on by Assignee

Waiting

Already worked on the task but currently on hold, for example, Engineer has to stop working because of a more urgent issue, or ticket was automatically transitions from "Waiting for Customer" or "Waiting for Third Party" and the engineer will work on this again soon.

Waiting for Third Party

More specific than waiting, that means a third party like upstream or support is blocking the continuation

This state doesn’t include waiting on the customer

Waiting for Customer

We can’t work on this task as we the customer needs to do something first (test, give feedback, answer a question) but the task isn’t considered done from our side yet.

Waiting for Internal Feedback

Task isn’t finished but waits for a VSHN internal feedback before it can be continued (code review, …)

Do not change the assignee, but mention the one you’re waiting for

Waiting for Maintenance

Everything is prepared and the next step in the task needs to be done during a planned maintenance window (for example, weekly maintenance window).

Missing Information

The issue needs more information before it can be triaged or the ticket quality is in an unusable state. Mostly used during triage by 1st Ops.

Internal Review

The issue is done (all task deliverables completed) and should be reviewed by a work mate before closing.

Change assignee to reviewer

Customer Review

The issue is finished (all task deliverables completed, internal review done where feasible) and the customer informed, waiting for customers feedback.

When no feedback from customer, close issue after 1 week

Done

Finished. Nothing can be done anymore on this issue. If something pops up after putting an issue in the Done state, a new issue needs to be created

To view the current active workflow, click on "(View Workflow)" next to the "Status" field

Transitions

Some transitions have special requirements.

Transition	Requirement
In Progress → Waiting	Write a comment why the issue is now in waiting state
In Progress → Waiting for Third Party	Write a comment why the issue is now in waiting for Third Party state and who you are waiting for
In Progress → Waiting for Customer	Write a comment that clearly says what we expect from the customer, for example, "Please test X," "Please show me how to reproduce this," etc.

Transition

Requirement

In Progress → Waiting

Write a comment why the issue is now in waiting state

In Progress → Waiting for Third Party

Write a comment why the issue is now in waiting for Third Party state and who you are waiting for

In Progress → Waiting for Customer

Write a comment that clearly says what we expect from the customer, for example, "Please test X," "Please show me how to reproduce this," etc.

Chore States

In use by the following Issue types: Chore, Operations

State	Meaning
Running	This issue is handled and can be worked on
On Hold	Currently nothing should be done here
Closed	Contract has ended

State

Meaning

Running

This issue is handled and can be worked on

On Hold

Currently nothing should be done here

Closed

Contract has ended

Project states

In use by the following Issue types: Project, Project Milestone

State	Meaning
New	Sales process is completed (Project Initialization) or conditions are set to define a new internal project. The project is being defined.
Backlog	The project is defined but there is no need to plan the project yet, for example: no immediate need, no due-date, focus lies on other projects
In Planning	Project is currently being planned - not work should be done now
On Hold	Project was in progress but is now paused.
Running	Project is running
Review	All task and deliverables are done or handled, and the project is in review (internally or with the customer).
Closed	Project is done. There are no further actions taking place.

State

Meaning

New

Sales process is completed (Project Initialization) or conditions are set to define a new internal project. The project is being defined.

Backlog

The project is defined but there is no need to plan the project yet, for example: no immediate need, no due-date, focus lies on other projects

In Planning

Project is currently being planned - not work should be done now

On Hold

Project was in progress but is now paused.

Running

Project is running

Review

All task and deliverables are done or handled, and the project is in review (internally or with the customer).

Closed

Project is done. There are no further actions taking place.

Project and Operations Reporting

There are some custom fields available which help with Project and Operations reporting.

Operations and Chores

Field	Usage
Total logged time (h)	Sums all logged work of issue links of type "is blocked by." Or in case of a Chore, all logged time in this Chore
Monthly Budget (h)	Hours which can be spent on this Chore / Operations per month (editable field)
Mt Budget Used (%)	Percentage of "Mt Budget Used (h)" vs. "Monthly Budget (h)" of the current issue
Mt Budget Used (h)	Sums all logged work of issue links of type "is blocked by" from the current month. Or in case of a Chore, all logged time in this Chore from the current month.

Field

Usage

Total logged time (h)

Sums all logged work of issue links of type "is blocked by." Or in case of a Chore, all logged time in this Chore

Monthly Budget (h)

Hours which can be spent on this Chore / Operations per month (editable field)

Mt Budget Used (%)

Percentage of "Mt Budget Used (h)" vs. "Monthly Budget (h)" of the current issue

Mt Budget Used (h)

Sums all logged work of issue links of type "is blocked by" from the current month. Or in case of a Chore, all logged time in this Chore from the current month.

JQL Example - Budget more than 90% used

(issuetype = Operations OR issuetype = Chore) AND status = Running AND "Mt Budget Used (%)" >= 90

Projects

Field	Usage
Work remaining (h)	Sums all remaining estimates of issue links of type "is blocked by" and state not Done
Total logged time (h)	Sums all logged work of issue links of type "is blocked by"
Estimation vs. Actual (%)	Percentage of "Total logged time (h)" vs. Original Estimate of the current issue

Field

Usage

Work remaining (h)

Sums all remaining estimates of issue links of type "is blocked by" and state not Done

Total logged time (h)

Sums all logged work of issue links of type "is blocked by"

Estimation vs. Actual (%)

Percentage of "Total logged time (h)" vs. Original Estimate of the current issue

JQL Example - Project Estimation at 90% used or more

(issuetype = Project AND status = Running) and "Estimation vs. Actual (%)" >= 90

Labels

We use labels to tag issues. This makes it easier to tie similar issues over the whole JIRA together. Here is a list of known labels and their intentional use.

Label	Use	Special Use
Support	Internal or customer (technical) question, nothing is broken and it’s not an order to change something (yet)	Used in filters to identify an Operations issue
GL	Issues which have been created during GL Meetings.
Incident	Something is broken, Host or Service down and the user / customer is affected / blocked	Used in filters to identify an Operations issue
Problem	Something is broken or not as it should be. The customer / user isn’t blocked. Potential reason of a past or future incident, can be a follow-up from an Incident	Used in filters to identify an Operations issue
Change	Something needs to be created, added, changed and isn’t big enough for a Project / Team Task	Used in filters to identify an Operations issue

Label

Use

Special Use

Support

Internal or customer (technical) question, nothing is broken and it’s not an order to change something (yet)

Used in filters to identify an Operations issue

Issues which have been created during GL Meetings.

Incident

Something is broken, Host or Service down and the user / customer is affected / blocked

Used in filters to identify an Operations issue

Problem

Something is broken or not as it should be. The customer / user isn’t blocked. Potential reason of a past or future incident, can be a follow-up from an Incident

Used in filters to identify an Operations issue

Change

Something needs to be created, added, changed and isn’t big enough for a Project / Team Task

Used in filters to identify an Operations issue

Obsolete Labels

Responsible Ops
Improvement
AppDev
SRE
and many more

Obsolete Labels should be removed and must not be used anymore!