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.

Useful Jira Chores for Booking Your Time

At VSHN we use Jira to keep traces of all of our activities, including those that don’t belong to a project. Use the tickets below to track your time according to your workweek.

Task Ticket

Daily Standup

VINT-1622

Personal management 2.0

VINT-1714

Informal Meetings

VINT-1709

Mail Cleanup

VINT-1707

Monitoring Operations

VSHNOPS-2313

Office Maintenance

VINT-806

Personal Workstation Maintenance

VINT-1717

Sick Leave

VINT-739

Ticket Triage

VSHNOPS-2312

Timesheet tasks

VINT-1706

Weekly Teammeeting

VINT-1708

Squad Planning

VINT-1837

Squad Retrospectives

VINT-1836

Handbook Maintenance

VINT-1321

Wiki Maintenance

VINT-1446

There are other, similar tickets that you might use, depending on your squad; for example, the Capella Squad uses ticket VINT-1033 to track time for their Planning and Backlog Refinement meetings. Inquire your lead for those of your own squad!

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.

add search engine

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

jira project

A project with a start and a defined end.

Reporter: CAM or Stakeholder
Assignee: Project Manager

jira project milestone

A milestone in a project.

Reporter: Project Manager
Assignee: Project Manager

jira operations

An ongoing "project," has no end (daily business)

Reporter: Project Manager
Assignee: Project 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

jira request

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

Reporter: Customer
Assignee: None

jira task

A task in a project that’s being done by a VSHNeer; the actual work entity.

Reporter: Anyone
Assignee: VSHNeer

jira chore

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

Reporter: Project 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 squad (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.

diagram-blocking

Jira Workflow

jira workflow
This workflow applies mainly to technical tickets and tickets from tech squads. 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 Squads and Chapters and then selected by Squads. Usually not urgent tasks start in the Backlog.

Selected

Chosen by a Squad 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 does not 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.

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

Project states

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

State Meaning

Open

Not in use

In Planning

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

On Hold

On hold

Running

Project is running

Review

Finished and in review

Closed

Project is done

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.

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

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 / Squad 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!