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 |
|
Personal management 2.0 |
|
Informal Meetings |
|
Mail Cleanup |
|
Monitoring Operations |
|
Office Maintenance |
|
Personal Workstation Maintenance |
|
Sick Leave |
|
Ticket Triage |
|
Timesheet tasks |
|
Weekly Teammeeting |
|
Squad Planning |
|
Squad Retrospectives |
|
Handbook Maintenance |
|
Wiki Maintenance |
| 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 
|
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 |
|
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 |
|
Used to group different categories of work or services on the customer side; not used in project management. |
Reporter: 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 |
|
Tasks, of a Project, a Milestone, or Operations. This is where the actual work is done. |
Reporter: undefined, usually the creator |
|
A recurring task (like meetings, project management, daily operations, etc.) |
Reporter: Project Manager or Service Manager |
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.
|
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 |
|---|---|
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. |
(issuetype = Operations OR issuetype = Chore) AND status = Running AND "Mt Budget Used (%)" >= 90Projects
| 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 |
(issuetype = Project AND status = Running) and "Estimation vs. Actual (%)" >= 90Labels
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 |