Issue Management using JIRA Version 2.22.

0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Objective
This SOP is the formal guideline that defines the OpenText standard procedures for all Issue Management using JIRA; its
purpose is to support the management of Product Development projects in an agile way.

Scope
This SOP applies to all locations and is effective for all Product Development projects that are managed in an agile way.
Since requirements, bugs and escalations are concurrently tracked in the same project(s), all issues ought to receive the
same consideration during a release cycle.
Additionally, this document is not meant to replace the JIRA user manual, it merely describes how the JIRA tool is to be
employed in support of the agile development environment, which is defined by the formal guideline set out in the IDP
Framework SDLC-00240. Process Dashboard

Details
This SOP defines the procedures and methodologies for the issue management (defect tracking and requirements
tracking) process throughout the organization.

Acknowledgements
The following colleagues have contributed to the document by authoring, reviewing, and/or making suggestions for
improvements:

Jacey Kennedy Brad McIlmoyl Tara Bourbeau

Ernst Kopp Jennifer Stanley Heidi Steinmann

Dmitry Nekrasovski Scott Loveland John Postma

Tim McCrabb

Roles & Responsibilities

Roles are defined in SOP-00138_Unified Role Model

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 1 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

1 JIRA Basics
1.1 System Information
JIRA is available at: https://jira.opentext.com
JIRA is only available from inside the firewall. Users not on the OpenText network must use VPN to gain access.

1.2 User Accounts

To request a login account for JIRA, a user or their manager must run the Tools Access Workflow. In the Attributes
section of the workflow, the “JIRA” checkbox must be checked. The workflow will then proceed to the reporting manager
to approve the access, and then to the system administrators to setup the account. Users will receive a notification once
their account is available.
Users log in to JIRA using their OpenText username and password. The username is the ID portion only, not the email
address or qualified domain name. If a user receives an error message about an invalid password, their account may be
temporarily locked out and they should wait 15 minutes and try again. The password is automatically kept synchronized
and cannot be reset or changed in JIRA.

1.3 JIRA Concepts

Project
A JIRA Project is a container used to group all the issues for a product. A separate JIRA Project can be created to
track the issues for a specific development project, but this is less common.
Version
Versions are used to manage product releases and the scheduling of issues. They are also used to manage the
product backlog.
Agile Board
Agile Boards are used to track the work for a development project that is using Scrum or Kanban agile
development processes. Boards are used to manage backlogs, plan sprints, update work status and report on
the development project.
Issue
Issues are the main entity in JIRA. They describe something that needs to be worked on: a business requirement
to be implemented, a bug that needs to be fixed, an escalation from customer support, or some other kind of a
task. The lifecycle of an issue is managed through a standard workflow.

1.4 Submitting a JIRA-related ticket to IT

Before submitting a ticket, check the Help Manual and Knowledge Base for JIRA.

To report a problem or to make a request, submit an IT ticket using OpenText Self-Service following the instructions in
How to Submit a Ticket on OT Self-Service Portal.

For JIRA, set these fields:

• Create Ticket For: “Information Technology”

• What System/Service is your IT Ticket about: “JIRA”

There is no need to submit a ticket to add users to a project role, add components or add versions. These can all be done
by the project lead and project administrators of each team.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 2 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

2 Issue Types
The different issue types in JIRA identify the different kinds of work that need to be done.
Requirements Management
• Epic - high-level product requirements that need to be broken down further before implementation
• UserStory - business requirements
• Feature Request – customer and internally reported requests for new or different functionality
• Theme - a legacy issue type which can be used to link multiple related issues together
• Roadmap – high-level item on the product roadmap for planning and reporting
Bugs Management
• Bug – customer reported defects and internally reported problems found during testing
• Defect Sub-task – internally reported problem found while testing a UserStory or other parent issue.
Task Management
• Task, Doc Task, Localize Task – work items that are neither bugs nor requirements
• Spike – investigation-based work items
• Sub-tasks (various) – different work items that may be part of implementing a UserStory or other parent issue. For
example, QA testing tasks.
Escalation Management
• Support Request – customer situations that require development assistance
• Escalation-Sub – a sub-task type for tracking customer requests to fix the parent issue; also used for the related
purpose of tracking work to produce patches fixing the parent issue.

2.1 Epic
An Epic is a description of high level functionality. Implementing it typically requires significant development effort
that spans multiple iterations using multiple User Stories. Epics are generally very large User Stories or a
collection of related User Stories that represent a portion of the vision of the product or release. An Epic would
typically be created by a Product Owner to assist with roadmap and release planning. Epics are treated as a
special issue type by the Agile Boards and are useful for managing and reporting on a development project. Issues
are linked to an Epic using the Epic Link field (and not by the normal Link functionality.) It is not required to create
Epics in JIRA unless they are needed to help group related issues together.

2.1.1 Epic Fields

The important fields to use for Epic are:

Epic Name Very short name used to identify the Epic on an Agile Board. It should
be no more than three or four words.

Summary Short summary of the Epic

Description Additional information to help define and explain the Epic.

Normally, the description should only define the business requirement.
It should not presuppose a specific implementation design. It is
recommended to reference the main persona that the implementation
of the requirement would benefit.

T-Shirt Size This can optionally be used to select a relative size for the Epic to help
with planning. Examples: S (small), M (medium), L (large) or XL (extra
large).

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 3 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

2.1.2 Epic Workflow

Status Description

Open The Epic has not been implemented.

In-Progress The Epic is currently being implemented.

(optional)
The ScrumMaster may update the Issue with In Progress to
help track the project state more accurately.

Resolved The Epic has been implemented. If there were test cases or
(optional) acceptance criteria that encompassed multiple UserStories, this
Status reflects that it’s now possible to test and validate these
criteria for the Epic.
The ScrumMaster would typically be the one to mark an Epic as
Resolved.

Closed The Epic has been fully implemented. If there were test cases
or acceptance criteria defined for the issue they have all been
satisfied.
Only Product Owners should close an Epic.
In addition to the regular Status workflow, an Epic has a
separate “Epic Status” value. When all work for an Epic is
completed, it should be marked as “Done” on the Agile Board
so it will no longer be shown within the Epic panel. Once an
Epic is marked Done it will not be available to select in the Epic
Link field.

2.2 UserStory

A UserStory describes a piece of functionality that, when built, will deliver business value to the customers and/or
end users of OpenText products. It is written from a user's perspective, focusing on the business problem to be
solved or the functionality/user experience to be implemented, instead of on a technical solution. It would typically
be created by a Product Owner.

Not all information about the story needs to be known upfront. The Product Owner and the team will discover the
details about the functionality itself, the customer and end user requirements around it, and the design of the
solution, as they are working on it. The discovery occurs through conversation and collaboration around the story.

A UserStory should be linked to the related Epic with the Epic Link field. This will enable the use of the Epic filtering
and reporting on the Agile Board, which is a useful project management tool showing progress towards completion
of Epics.
Each UserStory need to be assessed by the development team for whether an update to the product Help or
Documentation will need to be done by the Product Information (PI) team. The “Documentation Required” field
should be updated to either “Required” to automatically create a Doc Task for PI, or “Not Required”.

2.2.1 UserStory Fields

The important fields to use for UserStories are:

Summary Short summary of the UserStory

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 4 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Description Additional information to help define and explain the UserStory.

A persona name or role should be used to represent the specific

customer or user role whose needs are being met by this UserStory.

The recommended format is:

As <persona / role>, I want to <do something/goal> so that <reason>

Acceptance Criteria All UserStories must have “Acceptance Criteria”. Acceptance Criteria
are the requirements that must be met for a UserStory to be assessed
as done. Acceptance criteria are vital since they make clear what a
Product Owner expects and the Implementation team needs to get
done.
As the Product Owner and the Implementation team discover how the
user story is to be implemented through conversation and collaboration,
the acceptance criteria will evolve and may be linked to additional
documents.

Documentation Indicates whether Product Information team will need to update the
Required Help or Documentation for the UserStory. Can only be set using the
Documentation Required action.

2.2.2 UserStory Workflow

Status Description

Open Not implemented

To Do The UserStory is selected and ready to be implemented.

(optional)

In-Progress The UserStory is currently being implemented

(optional)

Resolved The UserStory has been implemented.

Verified The UserStory has been implemented, and all testing activities
have been completed.

Closed The UserStory has been fully implemented in accordance with

Definition of Done, Demo & Reviewed and Accepted by Product
Owner.

Only Product Owners should close a UserStory, but this

responsibility can be delegated.

2.3 Spike
At times, not all information is available to a team in order to confidently estimate a User Story and commit to
finishing it within an iteration. (E.g. when the team is unfamiliar with the technology/ architecture of the solution, or
needs to come up with a design solution.) In these cases, the team can decide to add a Spike to the Iteration
Backlog in order to research the User Story. To avert the team from doing excessive investigation and/or to control
scope the team agrees on a time box for the Spike. A Spike would typically be created by the Product Owner.
A Spike should be linked to the related UserStory with the Related link type.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 5 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

2.3.1 Spike Fields

The important fields to use for Spikes are:

Summary Short summary of the Spike

Description Additional information to help define and explain the Spike.

Normally, the description should outline the investigation objectives and
deliverables.

2.3.2 Spike Workflow

Status Description

Open The Spike has been created.

In-Progress The Spike is currently being investigated.

(optional)
The ScrumMaster may update the Issue with In Progress to
help track the project state more accurately.

Resolved The Implementer has completed their investigation and would

(optional) typically be the one to mark a Spike as Resolved.

Closed The Spike has been fully investigated with the results
documented/attached. The Product Owner would generally
close the Spike unless it was defined and created by an
Implementer.

2.4 Bug, Defect Sub-task

A Bug or Defect Sub-task is defined as a problem which impairs or prevents the functions of the product and
produces an incorrect or unexpected result. Typically bugs are entered by Customer Support, Development or QA.

Before logging a Bug, the reporter should attempt to replicate the issue. If the problem cannot be reproduced and
there is doubt whether it is a product defect or an environmental or configuration problem, then a Support Request
should be logged instead of a Bug. However, if the reporter is confident it’s a bug then even if it cannot be
reproduced it should be logged as Bug with the reasoning included.

Prior to logging a bug, the reporter should also perform a search of the existing bug repository to ensure that the
issue has not already been reported by another customer.

When a bug is found while testing/verifying a UserStory or other parent issue, either: the issue can be-reopened
with a comment to explain what’s not working; a new Bug can be created and linked to the UserStory with the
Related to link type, or a Defect Sub-task can be created under the issue.

2.4.1 Bug Fields

The important fields to use for Bugs are:

Summary Short summary of the bug. It is important that this field be as clear and
concise as possible, As the understanding of the bug evolves, this field
should be updated to ensure it is always an accurate summary. Any
text that helps to distinguish this bug from others, such as the error
message, should be included.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 6 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

A description of how the bug affects the functionality of the software, or If an applicable field template has
Description
the new feature or new functionality. been defined then it must be
The description must contain the following information: used.
1. Steps to reproduce.
2. What happened/what did you observe
3. What did you expect to happen?
The Description should be used to define and clarify the bug. It should
be detailed enough that Engineering does not need to ask questions to
fully understand the issue. (Comments should be used to document the
steps taken to address the bug.)
The customer urgency for the bug. The value reflects the customer’s This must be entered by
Urgency
own opinion of how serious the bug is and so the pressure to fix it. It is Customer Support or
used to make sure the urgent customer issues are clearly identified and automatically populated by
given proper attention. ServiceNow. It should reflect the
Impact and Urgency of the case
in ServiceNow.
The options are: It should not be changed by R&D
• P1 – very urgent without agreement from customer
• P2 – urgent support.
• P3 – normal It is not used for internal QA
• P4 – not urgent bugs.
• None – not applicable [default]
The severity of the bug. The reporter should enter an
Priority
initial assessment of the Priority.
The options are Blocker, Critical, Major, Minor and Trivial. The default This should be entered by
value is Undefined. Customer Support.
This can then be updated by the
Product Owner.
See the Prioritization section later in the document for more
information.
Setting to Blocker or Critical triggers special attention and should only
be used as defined.

Components The product area(s) to which this issue relates

Affects Version Product version for which the issue was reproduced. This field should Cannot be set from ServiceNow
be entered when entering new issues. so Support will enter Affects Build
instead and Engineering will set
If multiple versions are affected, be sure to include the earliest known
Affects Version during triage.
version.

Affects Build Product build version for which the issue was reproduced. This is typically entered by QA
Set by Customer Support from
ServiceNow.

Environment The environment (e.g. operating system, database, web browser, on- Customer Support must provide
prem, third-party cloud, etc) which was used when the issue was the customer environment details,
identified. This field MUST be entered when entering new issues. as well as any other
environments where it has been
replicated

Issue Category, Although these fields are not mandatory, teams may have adopted their These would typically be entered
Discovery and Frequency own policy for use. by QA

Globalization Type Used to track Internationalization and Localization defects, and to allow This is typically entered once the
for differentiation between the two. root cause of a Globalization
issue is identified.
Internationalization: a problem that prevents the product from being
properly localized, such as a hardcoded English string, a missing xlate,
a failure to respect regional/locale settings, an inability to process or
render extended characters, etc. These generally affect multiple

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 7 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

languages and have to be fixed by the development team.

Localization: a problem with how the product was localized, such as a
bad translation, a screen glitch, a layout problem, a cultural
insensitivity, etc. These normally are reported by customers and
typically affect a single language and have to be fixed by the
localization team.

Assignee In general, use “Automatic”. Only, if you are sure a specific person
should take care of a request assign the corresponding person.

Attachments Attached screenshots and logs as appropriate. If an attachment is too large or

contains confidential info, then
When localization or internationalization bugs are reported, it is
Support should place in a share
important that screenshots are attached.
where development has access
Confidential customer information must not be stored in JIRA.

TestCaseNumber Reference of test case number in the test case management tool This is typically entered by QA
when the bug is found during the
execution of the test case.

OTTR Test Case URL Link to the QA test case in the Test Case Management tool This is typically entered by QA
when the bug is found during the
execution of the test case.

Customer Name Customer(s) affected by the issue. Multiple customer names should be This is mandatory when entered
separated by a semi-colon. by Customer Support and is
automatically set by ServiceNow
This field can be overwritten by the ServiceNow integration so should
not be manually edited.

Ticket_PTS_Number Customer support reference case number. Multiple case numbers This is mandatory when entered
should be separated by a space. by Customer Support and is
automatically set by ServiceNow.
This field can be overwritten by the ServiceNow integration so should
not be manually edited.

Reported Count Number of times this issue has been reported. Teams can use this to This is automatically set by
track unique customers or failed test cases. ServiceNow.
This field can be overwritten by the ServiceNow integration so should
not be manually edited for customer issues.

Documentation Required Indicates whether Product Information team will need to update the Can only be set using the
Help or Documentation for the Bug. Documentation Required action

2.4.2 Bug Workflow

Status Description

Open The fix for the bug has not been implemented.

To Do The bug is selected and ready to be implemented.

(optional)

In-Progress The fix for the bug is currently being implemented.

(optional)

Resolved The bug has been fixed but not tested and verified. The
Implementer would be the one to mark a bug as Resolved.

Verified The bug has been tested and verified but there are still further
(optional) reviews or actions needed before it can be closed.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 8 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Status Description

Closed The bug has been fixed and tested and all work required for the
issue has been completed. It is typically closed by QA.

2.5 Task, Doc Task, Localize Task

Defines a change to be made that may require verification but does not require approval by the product owner to
close. If verification is needed, this may be done by QA but there are other situations where the verification may be
done by other roles. A task can be anything that the project team desires to facilitate project planning (ie. Build
infrastructure, environment setup/configuration, etc).

A Doc Task should be created for tracking all tasks to be assigned to the Product Information (PI) team related to
creating or updating the Help or Documentation. It should be linked to any issue(s) that define the implementation
details, using the “Documents” link type. Doc Tasks are only used to identify and track the work done by PI. If teams
need to track other documentation related work, this should be done using a “Task” type.

A Localize Task needs to be created for any new or changed product UI files that are currently or will be translated. It
should always include the source file names that are changed or added. If this is a standalone task, it should be
linked back to the English JIRA issue.

Tasks can be a standalone item or can also be linked to a related issue, such as a UserStory.

2.5.1 Task Fields

The important fields to use for Tasks are:

Summary Short summary of the Task

Description Additional information to help define and explain the task.

Normally, the description should outline the objectives and deliverables
of a task.

2.5.2 Task Workflow

Status Description

Open The Task has not been implemented.

In-Progress The Task is currently being implemented.

(optional)

Resolved The Task has been implemented. The Implementer would be

the one to mark a task as Resolved.

Closed The task has been fully implemented (and tested if applicable)
with documented results. If the task requires verification, it
would be closed by the tester otherwise the task would be
closed by the Implementer.

2.6 Sub-task, Documentation, Localization Sub-task

A sub- task is related to the parent issue. Implementing a UserStory or fixing a bug may require a break-down of

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 9 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

the work that needs to be tracked or assigned separately. A Documentation or Localization Sub-task is created to
track the required work for updating the documentation or for localizing the product. These sub-tasks would be
created by whoever identifies that the work needs to be done.
Ideally, all work required to fully implement an issue is done together in the same iteration as part of a strict
definition of done. When this is not possible, instead of creating a sub-task a parent level Task should be created
and linked to the issue so the work can be managed separately. For most teams, this means that the Doc Task and
Localize Task types should be used instead of creating Documentation and Localization Sub-tasks.

2.6.1 Documentation and Localization Fields

The important fields to use for Documentation and Localization sub-tasks are:

Summary Short summary of the sub-task

Description Additional information to help define and explain what changes are
required.

2.6.2 Sub-task Workflow

Status Description

Open The Sub-task has not been implemented.

In-Progress The Sub-task is currently being implemented.

(optional)

Resolved The Sub-task has been implemented. The Implementer would

(optional) typically be the one to mark the subtask as Resolved.

Closed The Sub-task has been implemented and verified. If the task
requires verification, it would be closed by the tester otherwise
the task would be closed by the Implementer.

2.7 QA Sub-task

A QA task related to the parent issue that is created in order to track the testing activities of the UserStory. A QA
Sub-task would typically be created by a QA analyst.

2.7.1 QA Sub-task Fields

The important fields to use for QA sub-tasks are:

Summary Short summary of the testing topic

Description Additional information to help define and explain the testing efforts of
the UserStory.

Test Case Number Reference of test case number in the test case management tool

OTTR Test Case URL Link to the QA test case in the Test Case Management tool

Test Information Information about the testing that was performed and the results.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 10 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

2.7.2 QA Sub-task Workflow

Status Description

Open The QA Sub-task has not been implemented.

In-Progress The QA Sub-task is currently being implemented.

(optional)

Resolved The QA Sub-task has been implemented. The Implementer

(optional) would typically be the one to mark a QA Sub-task as Resolved.

Closed All testing activities have been completed and documented. A

QA analyst closes the QA Sub-task.

2.8 Feature Request

A requested change for a new feature or change in product functionality. A Feature Request would typically be
created by Customer Support or the Product Owner.

Prior to logging a Feature Request, the reporter should perform a search to ensure that the issue has not already
been reported or is not documented as a known issue, deprecated feature, or limitation in product guides and
release notes.

If a UserStory is created to implement the request, the Feature Request should be linked to the UserStory with
the Related to link type. When the UserStory is closed, the related Feature Request can be closed. It is also
possible to convert a Feature Request issue type to a UserStory for implementation using the Move Issue action.

For simple product changes, it is also possible to implement, resolve and close the Feature Request itself.

2.8.1 Feature Request Fields

The important fields to use for Feature Request are:

Summary Short summary of the feature request

Description Additional information to help define and explain the request and If an applicable field template has been defined then it
the use cases including steps on what the customer is attempting must be used.
to perform, the expected outcome and why it is needed.

Urgency The customer urgency for the feature request. The value reflects This must be entered by Customer Support or
the customer’s own opinion of how serious the request is and so automatically populated by ServiceNow. It should reflect
the pressure to include it. It is used to make sure the urgent the Impact and Urgency of the case in ServiceNow.
customer requests are clearly identified and given proper
It should not be changed by R&D without agreement
attention.
from customer support.
The options are: `
• P1 – very urgent
• P2 – urgent
• P3 –normal
• P4 – not urgent
None – not applicable [default]

Affects Version Version of the product that the reporter is currently using. Cannot be set from ServiceNow so Support will enter
Affects Build instead and Engineering will set Affects
Version during triage.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 11 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Affects Build Product build version the customer is using Set by Customer Support from ServiceNow.

Customer Name Customer(s) affected by the issue. Multiple customer names This is mandatory when entered by Customer Support
should be separated by a semi-colon. and is automatically set by ServiceNow.
This field can be overwritten by the ServiceNow integration so
should not be manually edited.

Ticket_PTS_Number Customer support reference case number This is mandatory when entered by Customer Support
and is automatically set by ServiceNow.
This field can be overwritten by the ServiceNow integration so
should not be manually edited.

Reported Count Number of times this issue has been reported. Teams can use This is automatically set by ServiceNow.
this to track unique customers.
This field can be overwritten by the ServiceNow integration so
should not be manually edited for customer issues.

Documentation Indicates whether Product Information team will need to update Can only be set using the Documentation Required
Required the Help or Documentation for the Feature Request. action

2.8.2 Feature Request Workflow

Status Description

Open The Feature Request has not been implemented.

To Do The Feature Request is selected and ready to be implemented.

(optional)

In-Progress The Feature Request is currently being implemented.

(optional)

Resolved The Feature Request has been implemented. The Implementer

(optional) would typically be the one to mark the issue as Resolved.

Verified The Feature Request has been tested but there are still further
(optional) reviews or actions needed before it can be closed.

Closed The Feature Request has been fully implemented and tested
and there is no more work required. If the feature request was
linked to a UserStory, then it would be closed by the Product
Owner. If it was implemented unrelated to a UserStory, the QA
analyst would close the issue.

2.9 Support Request

A Support Request is a request from customer support to development requesting assistance.

E.g A customer has a question that is not covered in the documentation.
A customer has experienced a problem that cannot be reproduced, and may be caused by configuration
or environmental factors.

A Support Request would typically be created by Customer Support. A Support Request should only be logged
after review by Level 3 support or a team SME. This gives Support the best opportunity to resolve the issue
themselves before requesting Engineering resources for assistance.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 12 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Engineering is expected to give attention to all Support Requests and to provide timely assistance. However, to
formally escalate a Support Request, Customer Support should create an Escalation-sub task underneath the
Support Request.

If an investigation of the Support Request reveals the customer issue is caused by a bug or is a feature request,
the Support Request should be closed and a new issue created by Engineering to track the Bug or Feature
Request separately. The Customer Name and Ticket should be entered on the new issue, and Customer Support
needs to be informed so they can link the case to this new issue.

2.9.1 Support Request Fields

The important fields to use for a Support Request are:

Summary Short summary of the support request

Description Additional information to help define and explain the request Customer Support should include details on what has
by the customer. Include detailed steps on what the already been tried to help the customer.
customer is attempting to perform and the expected
If an applicable field template has been defined then it must
outcome.
be used.

Urgency The customer urgency. The value reflects the customer’s This must be entered by Customer Support or should be
own opinion of how serious the situation is and so the automatically populated by ServiceNow. It should reflect the
pressure to resolve it. It is used to make sure the urgent Impact and Urgency of the case in ServiceNow.
customer requests are clearly identified and given proper
It should not be changed by R&D without agreement from
attention.
customer support.
The options are: `
• P1 – very urgent
• P2 – urgent
• P3 –normal
• P4 – not urgent
None – not applicable [default]
The severity of the problem. The reporter should enter an initial assessment of the
Priority
Priority.
The options are Blocker, Critical, Major, Minor and Trivial. This should be entered by Customer Support
The default value is Undefined. This can then be updated by the Product Owner.

See the Prioritization section later in the document for

more information.

Version of the product that the reporter is currently using. Cannot be set from ServiceNow so Support will enter Affects
Affects Version
Build instead and Engineering will set Affects Version during
triage.
Affects Build Product build version the customer is running. Set by Customer Support from ServiceNow.

Environment The environment (e.g. operating system, database, web Customer Support must provide the customer environment
browser, on-prem, third-party cloud, etc) which was used details
when the issue was identified. This field MUST be entered
when entering new issues.

Attachments Attached screenshots and logs as appropriate If an attachment is too large or contains confidential info,
then Support should place in a share where development
Confidential customer information must not be stored in
has access
JIRA.

Customer Name Customer(s) affected by the issue. This is mandatory when entered by Customer Support and is
automatically set by ServiceNow.
This field can be overwritten by the ServiceNow integration

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 13 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

so should not be manually edited.

Ticket_PTS_Number Customer support reference case number This is mandatory when entered by Customer Support and is
automatically set by ServiceNow.
This field can be overwritten by the ServiceNow integration
so should not be manually edited.

2.9.2 Support Request Workflow

Status Description

Open The Support Request has not been investigated.

In-Progress The Support Request is currently being investigated.

(optional)

Resolved The Support Request has been handled. The Assignee would
(optional) typically be the one to mark the Support Request as Resolved.

Closed The Support Request has been answered and either a bug or
feature request has been logged or an acceptable resolution
has been provided to the customer. The issue is either closed
by the reporter, or closed by Engineering wjth agreement from
the reporter.

2.10 Escalation-Sub

An escalation-sub is a request for a fix for a bug, typically as an immediate patch. It can also be used to escalate
a customer need for a feature request or a support request. For each version that requires a patch a separate
sub-issue should be created. This is because each patch requires separate implementation and verification work
to be completed and so needs their own dedicated workflows. One issue should not have multiple fix versions for
different versions. An escalation sub-task would typically be created by Customer Support, the Development
Manager or the Product Owner.

Note: Additional reviews of bugs and the creation of patches outside the regular release cycle, creates extra
overhead for development. Before a patch is requested, Customer Support must provide justification and also
obtain approval for the request from the appropriate Level 3 (L3) staff or Support manager.

2.10.1 Escalation-Sub Fields

The important fields to use for an Escalation sub-task are:

Summary Short summary of the escalation.

Description Any additional information to support the escalation, including Support must explain why it is necessary to escalate the
product version and platform in which the patch is needed. parent issue and what has been tried to satisfy the
customer
If an applicable field template has been defined then it
must be used.

Affects Version Product version for which the issue is being reported. Customer Support must include the version the
customer is currently running.

Scheduled Patch Specific patch number to which the escalated issue will be
Number included.

Customer Name Customer affected by the issue This is mandatory when entered by Customer Support.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 14 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Ticket_PTS_Number Customer support reference case number. This is mandatory when entered by Customer Support.

2.10.2 Escalation-sub Workflow

Status Description

Open The Escalation-sub has not been implemented.

In-Progress The Escalation-sub is currently being implemented.

(optional)

Resolved The Escalation-sub has been implemented. The Implementer

would typically be the one to mark an Escalation-sub as
Resolved.

Verified The Escalation-sub has been tested and verified internally.

(optional)

Closed The Escalation-sub has been fully implemented and tested and
accepted by the customer. It is not necessary that a patch be
created and delivered, only that the customer has received a
response that allows the escalation to be closed. The issue is
either closed by the reporter, or closed by Engineering wjth
agreement from the reporter.

2.11 Release Notes

Release Notes are documents that are distributed with our software to customers that provide information specific
to each release.

A release note subtask would typically be created by a Product Owner but can be created by other implementers
when they want to ensure that something is added to this document related to the parent issue.

This is a legacy issue type that is no longer recommended for use. Instead, teams that wish to auto-generate
release notes from JIRA should use the Release Note field that is available on each issue. Teams that wish to
track work required for updating individual items in the releases note document can use the Task type.

2.11.1 Release Note Fields

The important fields to use for Release Notes sub-tasks are:

Summary Short summary of the issue

Description The description of this subtask should not contain a description of the
error itself, but the text that is intended to be published in the Release
Notes.

Comments Additional information to help the Product Owner to define and explain
the issue to be included.

2.11.2 Release Notes Workflow

Status Description

Open The Release Note has not been created.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 15 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Status Description

In-Progress The Release Note is currently being implemented.

(optional)

Resolved The issue has been added to the Release Notes. The Product
(optional) Owner would typically be the one to mark a Release Note Sub-
task as Resolved.

Closed The issue has been added to the Release Notes and reviewed
for technical accuracy by development and reviewed for style
and spelling by a PI resource. The Product Owner or PI
resource would generally close the Release Note Sub-task.

2.12 CAPA, ECCN

For information regarding the CAPA issue type, used only in the CAPA project, please refer to “SOP-00101
Corrective and Preventative Actions":
https://intranet.opentext.com/intranet/livelink.exe/open/88043886

For information regarding the ECCN Submission type and Defect Fix Confirmation type, used only in the ECCN
project, please refer to “SOP-00228 Export Control Classification Number Application Process”:
https://intranet.opentext.com/intranet/llisapi.dll/Open/88061152
And “SOP-00358 Release Definitions”: https://intranet.opentext.com/intranet/llisapi.dll/Open/88047204

2.13 Roadmap

The Roadmap issue type only exists in the ROADMAP project. The issues are used for roadmap planning and
reporting. Only product managers should create roadmap items and only for their own products.

2.13.1 Roadmap Fields

Summary Name of the roadmap item

Release Quarter Used to identify the quarter when the roadmap item is planned to be
released

Description Description of what it is and why it’s valuable

Product Name Used to be able to view all roadmap items for a product.
Can enter multiple.
Avoid acronyms. Omit "OpenText".

Business Unit Used so leaders can see all roadmap items in their own BU

OpenText Cloud Used so that roadmap content can be reported to ELT by OpenText
Cloud

Product Manager The owner responsible for updates. Also acts as the contact name.

Roadmap Theme If applicable, used to tag the roadmap with one of the global themes
defined by ELT for internal roadmap.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 16 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Big Bet If applicable, used to associate the roadmap item with one of the big
bet projects

Initiative If applicable, used to associate the roadmap item with one of the
defined initiatives

Feature Group Used when a feature has been split into multiple roadmap items so they
can be grouped together

Roadmap Category If applicable, used to identify the category of roadmap item.

Can select multiple options.

Competitor If feature is to close a gap or to beat a specific competitor, enter name

of competitor (name only)

Customers If feature is on the roadmap for a specific customer, enter name of

customer (name only)

Roadmap Change Used for reporting on changes to a roadmap plan

• Late Add: item added to a quarter after roadmap has already been
reviewed
• Deferred: Item moved to a later quarter after roadmap for the
quarter had already been reviewed

Roadmap Status Used to explain the current status of a roadmap item.

Details
If still on Backlog and not planned, explain why.
If Deferred, explain why.

Visibility Used to hide or show the roadmap item in reporting for ELT and
customers

Top Innovation by Used by PM to identify if roadmap item one of the top 3 for the product
Product for the quarter

Top Innovation by Can only be set by PM Leaders.

OpenText Cloud
Used to identify the top 3 items for their OT Cloud for the quarter

Link to WOW slide If a Top Innovation, enter URL to location of Wow slide explaining the
feature

2.13.2 Roadmap Workflow

Status Description

Backlog The roadmap item has not been planned, there is no timeline
for implementation and delivery.
The Release Quarter field should be blank.

Planned The roadmap item has been scheduled to a quarter.

The Release Quarter field should be populated

Chartered The roadmap item has been included in a project charter to be

implemented for an upcoming release.
The Release Quarter field must be populated.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 17 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Status Description

Released The roadmap item has been completed and is now available.

Cancelled The item has been removed from the roadmap and will not be
done.
The item should not be included in any roadmap reporting.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 18 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

3 Managing Issue Backlogs

Managing the issue backlogs of all open issues in the JIRA project is the responsibility of the Product Owner. These
actions are typically done in consultation and with the assistance of the development team.

3.1 Triage
Triage is the process to review all new customer issues and provide an initial response back to the customer about how
and when the issue will be addressed. This is primarily intended for Bugs, but the same process should also be used for
all new customer-reported issues.
The four main steps to process a newly logged customer issue are:
• Properly Defined. Verify the issue has been properly logged: check all fields are populated as expected, and
there is sufficient information to reproduce the bug or understand the feature request.
If not, then someone from the development product team must be assigned to follow-up with the Reporter to get
the missing information. JIRA should also be updated with a comment summarizing the problems.
If the issue is caused by a problem with another team’s product or technology, then create a second issue in the
other team’s project, copying all relevant information including priority and customer name. However, if the
original issue was simply created in the wrong project, it should be moved to the correct project of the team that is
responsible.
• Prioritization. Assess the severity of the issue. See the Prioritization section later in this document. If an issue is
assessed as Blocker or Critical then it should be handled outside the normal triage cycle to accelerate the
response.
• Affects Version: The integration with ServiceNow only sets the Affects Build field. During triage, the Affects Build
value should be used to set the Affects Version field.
• Accept as Valid. Decide whether the issue is valid and justifies spending effort to ever fix or not. If not, then the
issue should be closed. See the “Close Issue” section later in this document for Closing as Not Fixed.
• Triage. Assign the issue to a Fix Version in one of four categories. See the Administration-Versions section later
in this document for more detail.
1) Release Version. Issue has been tentatively scheduled to be fixed. This is a semi-commitment and
requires having confidence in delivering. The Fix Version is the name of the version or service pack
where it has been scheduled. The Version must have a release date defined in the project administration
pages so the month and year can be shared with customers along with the release name.
2) Backlog Version. Issue is on a short list of issues to be fixed that are not scheduled yet. This should be a
temporary category that is regularly reviewed. Most issues on a backlog version should be scheduled
within 3-6 months. Teams should identify a maximum number of issues that can safely be put in this
category and make sure the maximum does not get exceeded and issues do not remain here indefinitely.
3) No Plan Version. There are currently no plans to fix this issue. It depends on a multitude of factors if and
when the issue will be scheduled. Teams should implement a process to review all such issues on a
regular basis and whether they should be moved to a Backlog version, kept in a No Plan version, or
Closed. Teams should also rely on trigger events to review an issue again, including another customer
reporting the same issue, the original customer asking for an update, or the team starts work on related
issues. Issues with no activity for a whole year must be reviewed or actioned - customers will be told all
open issues are reviewed a minimum of once a year.
4) Hot Fix Version. Issue has been scheduled to be fixed in a one-off hot fix. This is a semi-commitment
similar to a Release Version. The reason for this category is that it is not practical to create a new
Version for every patch. Instead, the actual name of the patch should be entered into the “Scheduled
PatchNumber” field of the issue. The Fix Version must be set with a Hot Fix version (eg. “Hot Fix”) that
indicates the real name is in this other field. The release date of the one-off can be included as part of
the patch name, but typically one-off patches are developed and released quickly so the date can be left
implied.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 19 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

The Triage Service Level Agreement (SLA) between Engineering and Customer Support defines the following three
rules for new customer reported issues:
• Development will review Blocker and Critical issues within 4 hours of notification based on normal business hours.
• All other issues will be reviewed within one week
• Critical and Blocker issues are expected to be resolved within 30 days

It is the responsibility of the Product Manager to triage customer issues, however this responsibility can be delegated if it
is agreed.
All new issues must be reviewed within one week and should be triaged in that timeframe. However, it is understood that
some complex issues may require additional follow-up and investigation and will sometimes take more than a month to
complete the triage process.

3.1.1 Triage Meeting

There should be a weekly triage meeting with the product manager and representatives from development and
customer support. The meeting should review all new issues from the past week, plus any untriaged issues from
previous weeks. The purpose of the meeting is to communicate and explain the planned prioritization and
scheduling of new issues and get input from customer support. Teams with a high volume of new issues may
choose to meet more frequently, while teams with a very low volume can choose to meet less frequently or not at
all. The meeting can also be used to review all active escalations to report on their status and discuss prioritization.

3.2 Prioritization
The Priority field captures the severity of the issue. It can be used for any issue type but is mainly intended for
Bugs.

The default value is “Undefined”. The reporter should enter an initial assessment of the Priority. This can then be
updated by the Product Owner.

Each value has an implied priority for scheduling, described below. However, the actual scheduling will be
influenced by other factors, such as the pressure from the customer (reflected in the Urgency field), existing
commitments, future plans, and resource availability. A decision on scheduling should not alter the Priority value
which reflects the inherent seriousness of the issue.

Blocker: The product is unusable. A fix must be investigated immediately and made available
as soon as possible in a patch.
- stopping customer deployment, production could not run; loss of data such that it cannot be
reconstructed or there is a high cost to recovery.
- Internally: development, testing work is not possible
> Security Issues: Any “Critical” Security Severity Level defects as defined in Section 3.3 Security
Severity Level Assignment
> Performance Issues: Performance tests cannot be conducted due to a product bug causing
frequent or severe error.
Rules:
• All Blocker issues should be resolved within 30 calendar days of being reported.
• The product must not be released if it contains a Blocker issue.

Critical: A significant part of the product is broken. A fix should take priority over other
planned work and be made available in a patch.
- Crashes, severe memory leak, fundamental use-cases not possible.
- Internally: further development, testing activities will be impacted until the defect is fixed.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 20 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

> Security Issues: Any “High” Security Severity Level defects, as defined in Section 3.3 Security
Severity Level Assignment, that do not meet the criteria for Blocker.
> Performance Issues:
• Product crashes or experiences prolonged process hangs during load or endurance testing
• Severe memory leaks demonstrated during load or endurance testing
• Weighted average of timings in load tests degraded by >15% from the prior release
• Core operation degraded, no longer meets SLA targets - eg frequent interactive requests
complete < 2 secs. Degradation from previous release of >50%, pushing it over SLA
• Unexpected increase in hardware resource utilization rate, of >25% over previous release at
same load
• Product no longer meets criteria required for desired external certification (for example SAP
PQ)
> Usability Issues that:
a) Obstruct task completion: user unable or likely unable to figure out how to complete a
common or crucial task, or very likely to make important errors
b) Damages reputation: an immediate and noticeable negative impact on OpenText reputation
Rules:
• All Critical issues should be resolved within 30 calendar days of being reported.
• The product must not be released if it contains a Critical issue.

Major: An individual function is not working properly with high impact to users. A fix should
be scheduled, either for a patch or planned release of the product.
- Major loss of functionality.
-The problem affects a high number of users, or customer environments.
- Workarounds may be available but are inconvenient.
> Security Issues: Any “Medium” Security Severity Level defects, as defined in Section 3.3 Security
Severity Level Assignment.
> Performance Issues: Significant bottleneck on a core operation, or drag on general performance of the
product.
> Usability Issues that cause significant delay, effort, and frustration: user able to complete the task, but
with considerable degradation of user performance time and/or accuracy
Rules:
• All Major issues should be reviewed before a new release to verify deferring the fix is acceptable.

Minor: An individual function is not working properly with low impact to users. A fix should be
made, but not until after other higher priority issues and so may remain unscheduled.
- Minor loss of functionality
- Practical workaround is available.
- Only affects a small number of users or customer environments.
- Frequency of problem is sporadic.
> Security Issues: Any “Low” Security Severity Level defects, as defined in Section 3.3 Security Severity
Level Assignment.
> Performance Issues: Localized impact on an infrequent operation, or marginal degradation
> Usability Issues that result in either of the following:
a) Causes minor delay and irritation: issue slows users down slightly
b) Minor violations of guidelines that affect appearance or perception

Trivial: No impact on ability to use the product. A fix can be safely deferred indefinitely.
- Only occurs in an unsupported environment or configuration.
- Function does not work as intended but current behavior is acceptable.
- Very low impact, or very rare occurrence.
> Security Issues: Any “Info” Security Severity Level defects, as defined in Section 3.3 Security Severity
Level Assignment.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 21 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

For more information on prioritizing Usability issues, refer to the Usability Severity Levels wiki page.

If the product is to be deployed to an OpenText Cloud / Hosted / Commercial environment, the remediation
timelines set out in the GIS Security Deployment Requirements policy take precedence over the above rules
and must be adhered to. Any exceptions to the GIS policy must go through the GIS Security Policy Exception
Request procedure.

3.3 Security Issue, CVSS Score and Security Severity Level

Security related defects require special attention as our customers expect timely responses to protect their business,
systems, and data.
When a security issue is identified:
• the Security Issue category checkbox must be checked in the Issue Category field
• the appropriate Security Severity Level (SSL) must be selected.
• To assist in determining an appropriate Security Severity Level, the Common Vulnerability Scoring System
(CVSS) is available. The CVSS Score field captures the calculated score (from 0 to 10) which drives the
appropriate and consistent Severity Level.
• the “Discovery” must be set with the SEC option that best reflects how the issue was discovered. Explanations
of the options are available here.
Each product team’s assigned Security Advocate is available to help determine an accurate CVSS Score and appropriate
Severity Level. The Security Engineering Team can also be contacted to provide guidance on the assessment.

CVSS Score Security Severity Level Minimum Priority

9.0 – 10.0 Critical Blocker

7.0 – 8.9 High Critical

4.0 – 6.9 Medium Major

0.0 – 3.9 Low Minor

Security Issue / Risk Treatment Rules:

• For all defects with a Security Severity Level of Critical, High, Medium or Low (not Info), the Product Manager
must approve, and their explanation must be added to the JIRA issue as a comment or an attachment as
evidence, for any of the following scenarios:
o A security issue is not resolved within the defined deadlines (Interim Risk Acceptance)
o A security issue is closed as “Won’t Fix” (Permanent Risk Acceptance)
o A security issue is downgraded, either the “Security Severity Level” or “Priority” value
• For all defects with a Security Severity Level of “Critical”, “High” or “Medium” (Priority of Major or higher), these
must be reviewed for each new product release, or minimum once a year. If it is decided to defer the issue again
(Interim Risk Acceptance), the evidence that the Product Manager has approved the new deferral must be added
to the JIRA issue as a comment or an attachment, each time it is deferred.
• The full handling rules for security issues, including required and recommended times to mitigation, are defined in
SOP-00384 Product Security Assurance Program.

3.4 Ordering
Issues on the backlog should be ordered by the Product Owner. For more information about ranking issues, see
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 22 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

the Agile Board section.

Business Value
This is a number field. It can optionally be used by the Product Owner to record a numeric assessment of the
business value of individual issues to help with selecting which issues to schedule to a release. A higher number
represents a higher value. Each team can define their own ranges and values to use. The Business Value
together with the Story Points estimate can be used to calculate a relative ROI (Return On Investment) on issues.
PM Commitment
These radio buttons can be used to identify whether the issue is mandatory to deliver or not. The two options are
None and Mandatory, and the default is None.
This field should be used to track the mandatory items from the Project Charter, or for any planning process
where the committed deliverables for a release are defined. It can also be used to identify individual customer
commitments.
Typically, only the product manager can decide an issue is mandatory and so the field should only be set by
product management or in agreement with them.
DevPriority
The possible values are: 1, 2, 3, 4, or 5. It can optionally be used by the Product Owner to record a high-level
assessment of the relative order that issues should be done to help select issues for a release. DevPriority allows
the definition of an alternate high-level ordering for issues separate from the Priority values. For example, a Minor
issue may be scheduled immediately to satisfy an important customer. Or fixing a Critical issue may require large
architectural changes and a fix has to be deferred.

Rank1

This is a legacy field which is being phased out with the introduction of JIRA Agile and should not be used.
Instead of entering a decimal value on each issue, use the ranking feature of the Agile Board to order the backlog.

3.5 Scheduling
Issues are scheduled by the Product Owner. New issues are triaged and the Fix Version is set to either a Release
version, Hot Fix version, Backlog version or a No Plan version.
Scheduling to a Release or Hot Fix
• Issues that have been committed to a customer for a release or that are confidently expected to be
implemented in a release, must have the Fix Version field set to the appropriate Release Version. These
represent semi-commitments to customers.
• Issues scheduled to a release should be included on a development project Agile Board and ranked near
the top of the backlog.
• Issues assigned to a Hot Fix version should be treated the same, and are expected to be ordered very
high on the backlog of an Agile Board.
Scheduling to a Sprint
• Issues are scheduled to a Sprint by assigning to a Sprint on an Agile Board during an iteration planning
meeting.
Unscheduled Issues on a Backlog Version
• Issues on a short list to be fixed but that are not scheduled yet must have the Fix Version field updated to a
Backlog version.
• Issues on a backlog version can be included on an Agile Board so they can be properly ordered in the

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 23 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

board backlog.
• All issues assigned to a backlog version should be regularly reviewed to determine if they can confidently
be scheduled to a Release version yet. If a planning meeting schedules an issue from a Backlog version
to the next Sprint, then the Fix Version should be updated to the Release version.
• Customers are told that issues on a Backlog version are on a short list to be scheduled within 3-6 months.
When issues are remaining in the short list for longer periods, then there are probably too many issues on
the Backlog versions and the list must be reviewed and some issues updated to a No Plan version instead.
The maximum number of issues that can safely be assigned to the Backlog versions needs to be
determined by the team based on experience.
Unscheduled Issues on a No Plan Version
• Issues not a short list to be fixed must have the Fix Version field updated to a No Plan version.
• Teams should implement a process to review all such issues on a regular basis and whether they should
be moved to a Backlog version, kept in a No Plan version, or Closed. Teams should also rely on trigger
events to review an issue again, including another customer reporting the same issue, the original
customer asking for an update, or the team starts work on related issues.
• Issues with no activity for a whole year must be reviewed or actioned - customers will be told all open
issues are reviewed a minimum of once a year.

Release Timebox
The Release Timebox dropdown can be used to help manage planning processes based on time periods instead
of release versions. For example: issues from any project that are planned for the third fiscal quarter of 2016 can
select the “2016.3” value.
New values can be added to the dropdown by submitting a ticket to IT. Requests will then be validated by the
project managers from the groups currently using this field.

3.6 Bulk Import UserStories

If it is necessary to work on building and revising a set of requirements external to JIRA, these can be bulk
imported into JIRA. This is only intended for uncommon situations and the Product Owner should normally add
new User Stories using the JIRA interface.
To bulk import UserStories:
• Download the most recent JIRA Import Template
• Populate the Excel spreadsheet following the instructions
o Enter project and reporter information on Cover tab
o Enter the issue details on the Import tabs. Do not use characters: \ * & “
• Submit a ticket to IT with the file to perform the bulk import
• After the import, use the Bulk Change feature from the JIRA interface as needed to set Component, Fix
Version and any other data.
The guideline for use is 20-60 issues, and no more than once or twice per development project. To add fewer
issues, use the web interface to add individually. For more issues, a data migration project may be more
appropriate.

3.7 Dependencies
When one team has a dependency on another team, a link of type “Depends on” should be created from the issue
in one project to the issue in the other project. If the issues do not exist they will need to be created first. The
issues can be of any type.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 24 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

The requestor must edit the issue in the other team’s project to set the “Requested Completion Date” when the
work should be completed. If multiple teams have a common dependency on the same issue, the Requested
Completion Date would be the earliest requested date from all teams. If a team is blocked because the
dependency is not being delivered as agreed, the issue in the other team’s project should have Priority set to
“Blocker” and a comment added to explain
The PM (or designate) of the team responsible to deliver the dependency should edit the issue in their project to
set the “Committed Delivery Date” when the team will deliver the work. If the delivery date slips, then the
Committed Delivery Date must be updated with the new value. Use the Comments to record other significant
updates so there’s full visibility of the history to anyone looking at the issue.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 25 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

4 Working on Issues
This is the primary workflow in JIRA:

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 26 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

4.1 Estimation
There are two levels of estimates within a given project. The product backlog is estimated using Story Points and the
iteration backlog is estimated in hours.

Story Points

UserStories and other issues on the backlog are estimated in story points and not directly linked to hours or days.
This high level estimation is done based on the relative sizes of the User Stories, producing consistent estimates
without requiring detailed analysis of the functionality. Stories are estimated relative to a baseline story that is
already estimated. A baseline story is a small story that is well understood by the team. The estimate is entered into
the Story Points field of the issue.

The velocity of a team is the total number of story points they complete each iteration and the velocity can be used to
help with planning. The act of estimating is also valuable in itself because it forces the team to validate their shared
understanding of the requirement. Estimating should be done at the lowest level possible.

Original Estimate

Original estimations are a time based estimate of how long it will take to complete each of the work task(s) in the
iteration. Original estimation of the Iteration Backlog is an input to the iteration burndown charts which provides
transparency as to how the Iteration is progressing. The team updates the Remaining Estimate field of all work
items every day. The sum of the Remainder is used for charting the Iteration Burndown. It allows the team to
understand the progress they have made and if they are on track to meeting their iteration goal. All estimates
should be entered into JIRA in hours (E.g 5h)

4.2 Documentation Required

All product changes need to be assessed for whether an update to the product Help or Documentation may be
needed by the Product Information (PI) team. The “Documentation Required” field defaults to Undefined and should
be updated to either “Required” or “Not Required” as appropriate using the “Documentation Required” workflow
action. Documentation Required should normally be set during sprint planning.
Setting the value to “Required” will automatically create a new Doc Task issue, linked to the issue using the
Documents/Is Documented By link type.
• The Summary of the Doc Task will be a copy of the issue summary with a “PI:” prefix. The Fix Version will
also be copied
• The Comment entered on the window will be used as the Description in the Doc Task and should explain
what documentation updates may be needed.
• Resaving the Required value again will create a new Doc Task each time. Therefore, the Documentation
Required action should only be used to change the value or when multiple Doc Tasks for an issue are
needed.
The Documentation Required field must be updated to either Required or Not Required for all issues in a release of
type: UserStory, Feature Request or Bug to ensure all issues have been properly assessed and documentation
updates do not get missed.
• Teams should create a filter for issues with an Undefined value to make sure all these issues are getting
properly assessed in a timely manner.
• Teams should set the Documentation Required field to “Required” on any issue where Help or Documentation

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 27 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

updates are needed, regardless of the issue type.

• Teams can set the value to “Not Required” on an issue if a Doc Task was previously created that already
describes the documentation updates needed for the issue.

4.3 Mark as To Do
When an issue is identified by the product owner as what the team should be working on next, the Status can
optionally be marked as “To Do”. This can be used on a Kanban board to identify the queue items the implementers
can pull from when they are ready to start a new work item. Or it can be used to help separate items at the top of a
product backlog. Typically, only the Product Owner should mark an item as To Do.

4.4 Assigning Issues

It is important to ensure the Assignee of each issue always reflects who is expected to be reviewing or working on an
issue. All users should be able to use the “Assigned to Me” report to determine what items they are responsible for. If
a person is not expected to work on something then it should not be assigned to them and should not appear in their
Assigned to Me listing. As an alternate to using individuals as long-term placeholders, consider using special Fix
Version values to mark issues instead.
There are multiple ways in which you can assign an issue to a specific person. During creation of an issue, you can
assign using the Assignee field by selecting a person from the dropdown. If you do not select a specific user from the
dropdown list, then the issue is assigned “automatically”.
• If a Component is selected and a Component Lead has been defined (in the project administration page),
then it will be automatically assigned to the Component Lead.
• Otherwise, if a Project Lead has been assigned in the project administration it will be assigned to the project
lead.
• Otherwise, if there is no project lead, it will be Unassigned. Teams should have a defined process to ensure
all newly created issues are properly triaged.

After an issue is created, you can click on the Assign button and enter a person’s name or use the “Assign to me”
link. You can also set the Assignee by doing an Edit or by doing any workflow action.
Team
The “Team” field is for use when there are multiple development teams working on issues in a project. When a
decision is made to assign an issue to one of the teams then the Team field should be updated to track this. To add
a new Team value, submit a ticket to IT.

4.5 Start Progress

When a user clicks the Start Progress button, it marks the issue as being worked on with the status switching to “In
Progress”. Typically this is done by the implementer when they start work on an assignment. If the issue is
unassigned, this action will also automatically assign the issue to the user.
When an implementer is no longer working on an issue, they can use the “Stop Progress” action which will switch the
status of the issue back to “Open”. Implementers can also drag an issue between the Open and In Progress columns
on an Agile Board in Active sprints mode, or between To Do and In Progress.

4.6 Log Work

When working on an issue, the implementer should keep track of their time in order to update JIRA and the iteration
burn down charts. Note: it is only necessary to log work if the team is using the Iteration Burn Down Chart or if the
team decides to track their work within the tool.
Example of logging work against an issue:
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 28 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Implementer has a task that is estimated to take 10 hrs.

Scenario 1:
Works on it for 6 hours with 4 hours remaining work, as expected, update should be:
- Click on Log Work for the issue
- Time Spent = 6h
- Remaining Estimate – leave set to Adjust automatically
- Click log button

Scenario 2:
Works on it for 10 hours but still has 3 hours remaining on the task, update should be:
- Click on Log Work for the issue
- Time Spent = 10h
- Remaining Estimate – click on the “Set to” option and enter 3h
- Click log button

Scenario 3:
Works on it for 7 hours and has completed the task, update should be:
- Click on Log Work for the issue
- Time Spent = 7h
- Remaining Estimate – click on the “Set to” option and enter 0
- Click log button

Note: It is also possible to Edit an issue and update the Remaining Estimate field directly, without having to log work. This
can be done from the Edit screen or from the Agile Board using in-line editing in the Issue Detail panel.

4.7 Blocked
An issue can be in any status to transition to Blocked, with the exception of Closed. Transitioning an issue to Blocked
means the assignee has an obstacle that needs to be solved before work can continue. When setting to Blocked, the
Blocked Reason should be populated to explain the obstacle and the issue should be assigned to the person responsible
for following up on the problem.
Once the obstacle is removed, the issue can then be Reopened to continue planning or development, Resolved to
continue testing, or Closed if no more work will be done. The Blocked Reason should be cleared when the obstacle has
been removed.
Teams do not have to use the Blocked status. For issues with an obstacle, the alternative is to set the “Flagged”
checkbox field to “Impediment”. The main benefit to using the Blocked status is teams can implement a Blocked column
on their agile board which makes it easier to group and see all blocked issues. But since Blocked is not a step in the
development process and can occur at any stage, it may be preferable in many cases to leave the status and toggle the
Flagged property.

4.8 Review
This action requires the issue to be in the Status In Progress.
Transitioning an issue to Review means the implementer has finishing the coding and is ready for a review of the code
changes.
If the code review identifies further changes are needed, the issue should be Reset to In Progress again. If the code
review passes, the issue should be Resolved.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 29 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

4.9 Resolve Issue

This action requires the issue to be in the status of Open, To Do, In Progress, Review or Reopened.
Resolving an issue indicates that the implementer had finished working on the issue. The resolution is specified via a
dropdown box. The status is changed to Resolved.

4.9.1 Fixed
Means the issue is fixed, checked into the source code system and tested by the developer. Any issues that
modify the product and will require verification by QA, including new features, should use Fixed.
The important fields to use when resolving an Issue as “Fixed”:

Resolution Select Fixed from the dropdown list

Assignee The person who the issue should be assigned to for verification.
If unknown, assign to the QA Manager or ScrumMaster.

Fix Version This field should already be set but if blank enter the Release
version. The system enforces this as a mandatory field when
resolving as Fixed.

Build The next build that will include the fix.

Resolved
It is strongly recommended to enter the build number of the
version containing the fix for all resolved issues. This makes
identifying the version to be tested easier for the QA analyst.

Time Spent See section ” Log Work”

Release Note Summary of issue suitable for customers

Comments Any information relevant to verifying the issue

4.9.2 Done
Means the work for this issue has been completed. This should be selected for issues like internal to-do items that
do not modify the product or do not require verification by QA.
The important fields to use when resolving an Issue as “Done”:

Resolution Select Done from the dropdown list

Assignee The person who the issue should be assigned to for verification

Fix Version If the issue included a code change, set with the code branch
version.

Build If the issue involved a code change, this is the next build that
Resolved will include the change.

Time Spent See section ” Log Work”

Comments Any information relevant to verifying the issue

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 30 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

4.9.3 Not Fixed, Not Done

Means the issue was not fixed or done for any one of the reasons below. No code changes were required.
Cannot Reproduce
All attempts at reproducing this issue have failed. Reading the code produces no clues as to why this behavior
would occur.
Won't Fix
The issue will not be implemented into the product. This decision should only be made by a Product Owner.
Duplicate
The issue is a duplicate of an existing issue. In this case the issue must be linked to the duplicate within JIRA.
Incomplete
Not enough information is available for the Implementer to work on the issue.
As Designed
The expected result/behavior logged in the bug is deemed incorrect and the product is working as expected.
Unsupported Environment
The issue only occurs in an unsupported environment and will not be fixed.
Workaround
An acceptable workaround was provided instead of a fix.
Archived
Issues can be bulk closed based on the age and inactivity of the issue. When performing this action, the
resolution code should be set to “Archived”. This must never be used for Blocker or Critical issues or for any
Security issues.

The important fields to use when resolving an Issue as “Not Fixed, Not Done”:

Resolution Select from the dropdown list

Assignee The person who the issue should be assigned to for closing.
The issue may need to be assigned to the Product Owner to
confirm the resolution and to close the issue. In other cases, it
may need to be assigned back to the reporter to provide further
detail or confirm closing.

Log Hours See section 5.4 Log Work

Comments All relevant information detailing why the issue was not fixed.

4.10 Reopen Issue

This action requires the issue to be in the status Resolved, Verified or Closed.
Reopening an issue indicates that it has not been properly implemented, and should be reviewed again. Typically
this action will be performed after a failed test of an issue reported as resolved. The status is changed to
Reopened.
• Only the reporter or users assigned to one of the project roles of Administrators, Product Owner, or Team
Members can reopen a closed issue.
• If an issue has been closed during another project and the same issue is found, a new issue should be
created and linked to the original for historical purposes.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 31 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

The important fields to use when reopening an issue:

Assignee The person to whom the issue should be assigned.

Fix Version This field should already be set but edits to this field may be
required for rescheduling.

Build Tested The build the issue was verified against and deemed not fixed.

Build This field should be used if a team has a procedure that this
Resolved should be reset when reopening issues.

Comments Any information relevant to verifying the issue

4.11 QA In Progress
This action requires the issue to be in the status of Resolved. Marking an issue as QA In Progress indicates that
testing of the issue has now started. When setting to QA In Progress and the Assignee is left blank, the issue will be
automatically assigned to the logged in user.
For teams with a lot of resolved issues, using this status can help provide a clearer picture of the current sprint status.
But if this status does not add value then it should not be used to avoid unnecessary extra workflow steps.

4.12 Verify Issue

This action requires the issue to be in the status of Resolved or QA In Progress. Verifying an issue indicates that the
issue has been tested and verified completely as defined in the definition of done. All associated QA Subtask(s) have
been closed. This action is required for UserStories, and can be used for any other issue type when additional
reviews or actions need to happen after an issue has been tested but before it can be closed. An issue cannot be
verified by the same person who implemented it.

The important fields to use when verifying an issue:

Assignee The issue should be assigned to the Product Owner or to

whoever will be responsible for closing the issue

Build Tested The build the issue was verified against.

Test Case Reference of test case number in the test case management
Number tool

OTTR Test Link to the QA test case in the Test Case Management tool
Case URL

Test Information about the testing that was performed and the
Information results.

Time Spent See section ” Log Work”

Release Note Summary of issue suitable for customers

Comments Any information relevant to verifying the issue

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 32 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

4.13 Close Issue

Closing an issue indicates that there is no more work to be done. There are different ways in which an issue can be
closed:

4.13.1 Closing Issue as Fixed or Done

An issue is closed after all work for it has been completed. At a minimum, this usually means it was coded and then
verified by someone other than the implementer. Documentation updates or a demo in an iteration demo review
meeting may also need to be completed before an issue can be closed.
Closing an issue does not depend on a product release that makes the change available to customers or production.
Each individual issue should be closed when the work has been completed for that issue, typically during a sprint or at
the end of a sprint. Individual hot fixes are an exception and are closed only once the customer has accepted the
patch. Final regression testing of all changes in a release should be tracked through a separate test case
management system such as Ottr.
• Close Issue (Resolution = Fixed, Done) – The issue has been completed and has been fully tested. An
issue should not be closed as fixed without going through the resolved workflow process to be tested first.
• Approve Issue (Close) – applicable for UserStory only. The UserStory has been completed and accepted by
the Product Owner as per the definition of done.

Assignee The Assignee can be reset to Unassigned but this is not

mandatory.

Fix Version This should already be set but verified for correctness. Not available when closing from Verified.

Build Tested The build that was used for verification. Not available when closing from Verified.

Test Case Reference of test case number in the test case management Not available when closing from Verified.
Number tool

OTTR Test Link to the QA test case in the Test Case Management tool Not available when closing from Verified.
Case URL

Test Information about the testing that was performed and the Not available when closing from Verified.
Information results.

Time Spent See section ” Log Work” Not available when closing from Verified.

Release Note Summary of issue suitable for customers

Comments Any relevant information related to closing the issue that has
not been documented in the issue.

4.13.2 Closing Issue as Not Fixed, Not Done

• Close Issue (Resolution = Other than “Fixed” or “Done”) – The issue has not been fixed and work will no
longer be continued.
Note: Although you should change to the status “resolved” first, you can also go directly go to the status of
Closed.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 33 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

• Close Issue (Not Fixed) – Applicable to UserStory. The Product Owner has decided that this requirement will
not be included.

Resolution Select from the dropdown list. This is only available if the status
is still Open and issue has not been Resolved.
For a UserStory, the resolution “Fixed” and “Done” are not
available.

Assignee The Assignee can be reset to Unassigned but this is not

mandatory.

Fix Version No value should be set in this list.

Comments All relevant information detailing why the issue was not fixed.

4.14 Additional actions and fields

Throughout the whole process additional information can be provided by:
• Commenting on an issue
Collaborating on an issue is encouraged to be done as Comments on issues instead of through email
threads. This will help track the full history of an issue in JIRA where anyone can review it. A comment should
always be added when doing any work on an issue (assigning, changing status, updating) to improve
richness of the audit history.
Comments support rich text formatting. All text fields including Comments and Descriptions have a maximum
length of 32,767 characters.
• Linking to another issue
- Details/Is Detailed – used for parent/child relationships and the Traceability Matrix Report
- Duplicate – required when closing an issue as a duplicate
- Depends On – for tracking dependencies between issues
- Related to – general purpose linking of issues.
• Labels
Can be used to mark items that need to be grouped together. Especially useful for grouping issues from
multiple projects together.
• Performance Bulletin
Typically used by the Performance team, the Issued checkbox would be selected for an issue when a
Performance Bulletin has been issued to customers.
• Release Note
This field can be used to enter customer-facing text that summarizes the issue for inclusion in a release notes
document. Exporting these values for all bugs fixed in a specific release can help to generate the list of
Fixed Issues. Exporting these values for all unresolved bugs can help to generate the list of current Known
Issues in the release.
• KBA Number
This field is used by Customer Support as a reference number to a Knowledge Base Article.
• Set Schedule PatchMonth
This action is used to set the Scheduled PatchMonth field to identify when an issue is included in a Content
Server Cumulative Update release. Only users in the group “Monthly Patch Responsibles” can use this
action.
• Investment Theme
This field is used to classify work into one of several pre-defined categories. Business units can plan to

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 34 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

allocate a fixed percentage of time to various investment themes and then perform validation reporting
against the plan using this field. (Currently only used by BN.)
• PCR Number
This field tracks the Product Change Request workflow number related to the issue. (Currently only used by
BN.)
• Billing Project
This field tracks the SAP project name for billable work. (Currently only used by BN.)
• Structures
This plugin allows users to build and share hierarchal lists called Structures. A structure is used to help
manage larger backlogs or projects in a single view. There is no limit on the hierarchy depth of a Structure,
and it can include user-defined folders and all types of issues from different projects. The size of each
Structure must be kept under 10,000.
This feature is currently only available to selected teams while the impact on system performance and stability
is being evaluated.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 35 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

5 Agile Boards
Agile Boards are used to track the work for a development project. A development project is typically used to manage the
work for a product release, but it can be for any scope of work. The backlog can be ordered, issues can be estimated and
scheduled to an iteration, the status of work items can be updated, and progress reports can be run.

5.1 Creating a new Agile Board

A new board is created at the start of a new development project by the project administrator.
First, a new Filter should be created that will be used as the Board Filter that includes all issues scheduled for the release
and all issues on the release backlog. This is typically a filter based on Project and Fix Versions. The recommended
maximum for a board backlog is 200-300 issues. The filter must explicitly define which projects to include and should be
defined to ensure that two boards do not have overlapping contents.
Next, create the board. Locate the “-IDP Scrum Board Template” and Copy it.
• In the copy, enter the Board Name. The board name should be the same as the project name used in SAP and
Confluence. The standard is to use product name, version and code name. eg. “Document Manager 10.5
(Whistler)”. The version and code name are optional.
• The Board Filter that was created previously should be entered and the “Add Rank” button pressed to enable
Ranking.
• The board can be further configured however the team chooses.
The project in Confluence should be updated with a link to the Agile Board in JIRA.

5.2 Backlog mode

5.2.1 Ordering the Backlog

In Backlog mode, the Product Owner should order the issues in the Backlog section so that any items to be scheduled for
the next Sprint are at the top. Only users assigned the Product Owner role or Project Administrator role can re-order
items on the Board.

5.2.2 Sprints
note: JIRA Agile uses the term “Sprint” and IDP uses “Iteration”. These two terms are interchangeable.
Sprints are defined on the Agile Board by the project administrator. It is recommended to include the project code name
in the sprint names so that they are more easily distinguished from sprints on other boards. Eg. “Whistler Sprint 1”.

5.2.3 Iteration Planning Meeting

In the Iteration Planning Meeting, items on the backlog should be added to the Sprint being planned. As issues are
estimated, the values can be entered into the Issue Detail panel. Sub-tasks can also be added to issues, but only parent
issues are visible and can be assigned to the Sprint, and any sub-tasks must match the Board Filter for them to appear in
Active sprints mode and the reports.
At the end of the meeting, the Start Sprint action must be performed. The Start and End dates for the Sprint should be
entered. By default, the sprint length is two weeks but this should be changed to the actual iteration dates if they are
different.

5.3 Active sprints mode

This mode is used during the iteration. Team members can update the status of issues by dragging to the appropriate
column. The remaining estimate of issues can be entered in the Issue Detail panel and new sub-tasks can be created.

5.3.1 Flagging an Issue

During the iteration, a team member can flag an issue that requires attention by Setting a Flag. This will show the issue
with a yellow background. When the problem is addressed, then the Flag should be removed.
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 36 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Flags can also be added or removed by editing the issue and updating the Flagged field and one of the three
checkboxes: Impediment, Escalation, Waiting for Support. If one or more of these are checked the issue will appear as
flagged in Active sprints mode on the Agile Board. Using the Add Flag menu from the Agile Board will only check the
“Impediment” checkbox. Using the Remove Flag menu from the Agile Board will uncheck all Flagged checkboxes.
• Impediment: used to flag an issue as blocked in development
• Escalation: no standard use, but can be used by individual teams as desired
• Waiting for Support: used to flag an issue waiting for a response from outside the development team

5.3.2 Completing a Sprint

In the Iteration Demo Review meeting, once the iteration is over and all completed issues are closed, the Sprint can be
marked as Complete. Non-closed issues can either be moved to another planned sprint, or moved back to the top of the
board backlog for the next Iteration Planning Meeting. If a sprint is marked completed by mistake it can be reopened.

5.4 Reports Mode

Teams should use the reports in Reports mode to manage the iterations and the development project. They can be used
as a reference in the various iteration meetings.

5.5 Kanban Boards

Kanban is an agile development methodology that focuses on ensuring a steady flow of continuous work instead of using
fixed length Iterations.
Teams can create a Kanban Board instead of a Scrum Board. The steps are the same as above, except copy the “-IDP
Template Kanban Board”. A Kanban board has an optional Backlog mode, a Kanban board mode (equivalent to the
Active sprints mode of a Scrum Board) and 2 reports on Reports mode. The backlog is ranked on a Kanban board in
Backlog mode by ordering the issues in the Open status. The top backlog items that should be worked on next are
moved to the Kanban board by moving them to the “To Do” status.
When configuring a Kanban board, you can set “Issue Count” Constraints on the Columns with a maximum number of
issues in the In Progress and Resolved states that are appropriate for the team size. You can also configure the board to
automatically hide older completed issues.

5.1 Closing an Agile Board

Once a development project is over the Agile Board needs to be kept for audit purposes. The same filter and board must
not be reused for the next development project of the team.
To mark a board as closed, rename the Board and add the word “(Closed)” to the end, and add an “x” to the front of the
name so the board will be sorted at the bottom of the Manage Boards page.
Example: rename “Document Manager 10.5 (Whistler)” to “x Document Manager 10.5 (Whistler) (closed)”
If the same “Backlog” version value will be used for the next project, then to avoid overlapping boards the filter for the
closed project Board should be edited to remove the Backlog fix versions from the criteria.

5.2 Deleting an Agile Board

If a board was created in error, or the development project was merged with another Board, then the Agile Board can be
deleted.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 37 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

6 Project Administration
6.1 Creating a new project
To create a new project for managing the issues for a product, submit a ticket to IT. The ticket must include:
• The Project Name should be the (short form) product name. Example: “Document Manager”.

• The Project Key must be all uppercase letters, minimum 3 characters long and cannot already be in use.

• The OpenText Product associated to the project, if applicable. The product must exist in the Engineering
Reporting Product Hierarchy Tracker. The product value will also determine the Project Category value used for
the location of the project in the reporting hierarchy on the Quality Dashboard.
The person who submits the request will be setup as the Project Lead on the new project. The project lead can then add
other project administrators or change the Project Lead to someone else.
Projects in JIRA can also be created for other reasons than managing all the issues for a product. In these cases, use the
same method, enter an appropriate Project Name, and provide the reason you need the project in the ticket.

6.2 Versions
Versions are used to manage the backlog for a product and the scheduling of work to a release. There are four types of
Versions. Projects must follow this convention so that triage decisions entered into the Fix Version field can be properly
interpreted by customer support and shared with customers without confusion or misunderstanding as to their meaning.
Release Versions
• these values are used in the Fix Version field to track when an issue has been scheduled to a Release by the
Product Owner. They are also used in the Affects Version so the Reporter of an issue can indicate which
version(s) an issue is being reported against. These should be created for all releases, including version releases
and maintenance releases such as Service Packs.
• the values should be the friendly official name of the release, eg. 21.1, 21.2, etc. If you need more complex
values, add the additional text to the end. It should be possible to find all issues delivered in 21.2 by using the
JQL: fixVersion ~ "21.2*"
• each value must have a Release Date entered.
• Once a release version is released and available, the “Release” action should be used to mark the version as
Released. This is used to properly sort the versions within the JIRA interface.
• Once a release version is no longer needed and does not need to be used for either Affects Version or Fix
Version, it should be Archived.
Backlog Versions
• these values are used to track the open issues on the product backlog that are on a planned short list to be fixed
but are not yet committed to a release version.
• this should be a temporary category that is regularly reviewed. Most issues on a backlog version should be
scheduled within 3-6 months. Teams should identify a maximum number of issues that can safely be put in this
category and make sure the maximum does not get exceeded and issues do not remain here indefinitely.
• there can be a single Backlog version in the project. If there are multiple releases being planned, or if the single
release backlog needs to be divided into subsets, then multiple Backlog versions should be defined.
• the value must either be “Backlog” or start with “Backlog”, eg. Backlog 3.0, Backlog 2.2 SP1.
• the Release Date must be blank for these versions.
• Once a Backlog version is empty and no longer needed, it should be Deleted.
No Plan Versions
• these values are used to track the open issues for which there does not exist a plan for them to be fixed.
• teams should implement a process to review all such issues on a regular basis and whether they should be

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 38 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

moved to a Backlog version, kept in a No Plan version, or Closed. Teams should also rely on trigger events to
review an issue again, including another customer reporting the same issue, the original customer asking for an
update, or the team starts work on related issues. Issues with no activity for a whole year must be reviewed or
actioned - customers will be told all open issues are reviewed a minimum of once a year.
• there can be a single No Plan version in the project, or multiple No Plan versions can be defined.
• the value must either be “No Plan” or start with “No Plan”, eg. No Plan - Review Every 6 Months, No Plan - 2015
Candidates.
• the Release Date must be blank for these versions.
• Once a No Plan version is empty and no longer needed, it should be Deleted.
Hot Fix Versions
• these values are used to track when an issue is scheduled to a one-off hot fix patch when it would not make
sense to define a separate Release Version. In these cases, the real name of the patch is entered into the
“Scheduled PatchNumber” field of the issue and the special Hot Fix version is used in Fix Version to indicate to
look in that other field.
• there can be a single Hot Fix version in the project, or multiple Hot Fix versions can be defined.
• the value must either by “Hot Fix” or start with “Hot Fix”, eg. Hot Fix 2.x, Hot Fix 3.x.
• the Release Date must be blank for these versions.
• Once a Hot Fix version is no longer needed, it should be Archived.

Fix Version type Release Date Communication to Customers (status=not closed)

<blank> Pending Review (in next 7 calendar days).

Release Version must be populated Scheduled for <Version>. Issue has been tentatively scheduled to
be fixed.
The version name from JIRA is provided to customers.

Backlog must be blank Pending Scheduling. Issue is on short list to be scheduled soon (in
next 3-6 months)

No Plan must be blank Not On Roadmap. There are currently no plans to fix this issue.
Will be reviewed at least once a year.

Hot Fix must be blank Scheduled for Hot Fix. Will be fixed in a one-off hot fix.

6.3 Components
Components are sub-sections of a project that should be defined for the project. If a product has different people
responsible for different components this should be reflected in the component definitions in JIRA.
Note: When setting up components, you can choose to set a Component Lead so new issues created with the
component are automatically assigned to the correct person for review.

6.4 Assigning Users to Roles

6.4.1 Project Lead

Every Jira project has a project lead associated to it who has administrator privileges. Project leads can also be
configured as the default assignee for new issues created with no assignee. The ScrumMaster or Product Owner
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 39 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

is typically assigned the Project Lead Role.

6.4.2 Component Lead

A component can be assigned a component lead (i.e. Implementer). Unlike a project lead, a component lead does
not receive additional permissions.
Note: A Jira project can be configured is such a way that a new issue that is not explicitly assigned to a user will
automatically be assigned to the component lead of the first component this issue is associated with.

6.4.3 Project Role: Administrators

Project Administrators can configure a project’s Versions, Components and Role memberships. They can also
create an Agile Board for a project and manage the Sprints. The Product Owner (PO) and ScrumMaster should
be assigned the Administrators Role, as they are by default responsible for managing the versions and the
components to ensure continuity when either one is not available.

6.4.4 Project Role: Team Members

A project role that represents Implementers in a project. The default project configuration scheme has all JIRA
users listed in the Assignee auto-complete dropdown. To limit this list to just your project team, submit a ticket to
IT to have the permissions scheme changed to Assignee-Developer Permission Scheme. When this has been
configured, only users added to this role (plus the reporter) will be listed in the Assignee auto-complete dropdown.
Users assigned to the Team Members role (plus the reporter) will have permissions to reopen closed issues and
to edit the Watchers list of any issue in the project. Users should not remove another person from a Watchers list
without their consent.

6.4.5 Project Role: Watchers

Any user added to this role will receive an email notification for actions on any issue within the project, including
creation, edits, assignments, comments, workflow transitions and more.

6.4.6 Project Role: WatchersCreateOnly

Any user added to this role will receive an email notification for each new issue created within the project.
An email notification will also be received when an issue is moved into the project.

6.4.7 Project Role: Product Owner

The Product Owner is a legacy role. Product Owners should be assigned to the Administrators role.

6.4.8 Project Role: Users

Users added to this role can view the Field Templates defined for the project.

6.5 OpenText Product

Each project related to a product should have the correct product name selected in the OpenText Product field.
The field must be set correctly so the project is included properly in Engineering reporting. If a project is not
related to a product or is not an Engineering project, it should be left blank (none selected).
By default, updating the OpenText Product will also update the JIRA Project Category value, used for the location
of the project in the reporting hierarchy on the Quality Dashboard. If a project is related to a product but should be
excluded from Customer360 reporting because it’s an internal-only or legacy project, then check the “Exclude
from Customer360?” checkbox when updating the OpenText Product and this will set the Project Category to
“Unmapped~ERPHT”.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 40 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

The Product dropdown options are synchronized with the Engineering Reporting Product Hierarchy Tracker
(PHT). If a product is missing or has the wrong name in the dropdown, changes must be requested in the other
system by contacting erpht@opentext.com.

6.6 Closing a project

When a project is no longer needed and will not be used for any future activity, the project should be closed.
• The Project Lead submits a ticket to IT with the Project Name and Key and asks for it to be closed.
• The JIRA tools team will close any open issues as “Archived” and then update the project to be “READ ONLY”.
Issues can still be searched but no new issues can be added and existing issues cannot be edited.
The tools team will first check the email came from the project lead to help prevent accidental closures of the
wrong project or of projects still in use.
The project category will be updated to Unmapped~Closed and the “Exclude from Customer360?” checkbox will
be checked to remove it from the Quality Dashboard.
The tools team will also rename the project to add the word “(closed)”.
Example: “Document Manager” would be renamed to “Document Manager (closed)”.
This rename will make sure that closed projects can be easily identified inside of JIRA.

6.7 Special System Requests

Project administrators can make the following special system requests.

6.7.1 Enabling Ottr integration for a project

The “Ottr Test Case URL” field is available for issues in all projects so that an issue can be linked to a single test
case URL.
A more advanced integration can be enabled for projects that will show an Ottr tab on issues. This Ottr tab has
two sections:
• Test Case Definitions: this show all test cases linked to your JIRA issue that define the steps needed to
verify the issue. These links are usually created for a UserStory or QA Sub-task.
• In Test Runs: this shows test runs that have been linked to the JIRA issue. These links are usually
created after a test has failed to link the test run to a newly created Bug in JIRA.
To enable the full integration, both the Ottr project and JIRA project have to be configured. In Ottr, the JIRA
project key must be entered in the corresponding field of the Edit Project form of the Ottr project.
For JIRA, the process is to submit a ticket to IT and ask for the Ottr tab to be enabled for an individual project and
provide the project name and key.
More information about this integration is available here:
https://confluence.opentext.com/display/OTTR/Ottr+Information+in+JIRA

6.7.2 Enabling Source Control integration for a project

JIRA has integrations with each of the officially supported source control tools: Perforce, Subversion, TFS, Git,
and Mercurial. When an integration is enabled for a project, a corresponding tab shows in JIRA that lists all
change lists and files that have been linked to the issue. This makes it possible to understand both the reason for
a change (which is recorded in JIRA) and what was actually changed in the code (which is recorded in the source
control system.)
To enable an integration for a project, submit a ticket to IT and provide (a) the JIRA Project name and key, (b)

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 41 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

which source control tool you’re using, and (c) the server details of the source control tool.
More information about the integrations are available here:
• Git: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-+Source+Control+System+Integration+-
+GitLab
• Mercurial: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-
+Source+Control+System+Integration+-+Mercurial
• Perforce: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-
+Source+Control+System+Integration+-+Perforce
• Subversion: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-
+Source+Control+System+Integration+-+Subversion
• TFS (TFVC): https://confluence.opentext.com/display/RDOT/JIRA+Tips+-
+Source+Control+System+Integration+-+TFVC+(Team+Foundation+Version+Control)

6.7.3 Requesting new values for the Team dropdown field

A team dropdown field is available on each issue, with the same system-wide set of values used in all projects.
When a JIRA project is the responsibility of multiple teams, this field can be used to identify which team owns
which issues.
To request a new value to be added to the Team dropdown, submit a ticket to IT and provide the name of the new
team.
Team values must have a prefix so teams for the same group are sorted together. Use format Prefix-TeamName.
If a Team value is no longer needed, submit a ticket to IT to ask for the value to be archived. Archiving means the
value will not be listed in the dropdown anymore when setting the field on new issues, but existing issues with the
value will not be affected.

6.7.4 Requesting a new Group or changes to Group membership

Groups can be used in filters to show issues created by or assigned to a specific set of users. An in-list of user
names accomplishes the same thing. However when the in-list is used in multiple saved filters then making any
change (such as adding a new user) requires updating each of the filters using the in-list. By using Groups
instead, you only need to update the group.
To request a new group, submit a ticket to IT and provide (a) the group name, and (b) the list of users to include
in the group. To add or remove a user from the group, submit a ticket to IT and identify the group and the change
that needs to be made.
Because a new IT ticket is needed each time a group is created or updated, the use of groups should be
minimized and should only be requested after carefully considering other options.
To review the current membership of a group, this report lists all groups and their users:
https://confluence.opentext.com/display/RDOT/JIRA+Tips+-+User+Group+List

6.7.5 Requesting a special user account

Most user accounts in JIRA are created and linked to OpenText domain user accounts. However, it’s also
possible to request special user accounts that are linked to a distribution list email account, or are not linked at all.
Some scenarios where this can be useful are:
• A computer in the office is dedicated to showing JIRA dashboards, wallboards or agile boards on a tv or
monitor. A special account needs to be created so this computer can be logged in to JIRA all day using
that account instead of leaving the computer logged in under an actual user account.
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 42 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

• An entire team (often in Customer Support) needs to watch several key issues in a JIRA Project. A
special account in JIRA needs to be created that is mapped to a matching distribution list in Exchange.
Instead of having to add each person as a watcher on each issue, it’s only necessary to add the special
account as a watcher to each issue.
• A JIRA integration is being implemented using the JIRA API, and the custom solution needs a special
user account to login and perform actions that are not associated to an individual user.
To request a special user account, submit a ticket to IT and (a) explain the purpose for which it will be used, (b)
the name of the user account, (c) the associated email address, and (d) the owner who is responsible for this
account. The request will be reviewed, and if the purpose could introduce a security risk then it may be rejected
or certain conditions may be imposed. The password for the new special account will be provided via email and
should be kept private.
If the account is no longer needed, submit a ticket to IT to ask for it to be de-activated.

6.7.6 Defining Subtask Templates for a project

The “Create multiple Sub-Tasks” action allows users to create one or more sub-tasks in bulk under an issue,
including the ability to inherit or default fields. By default, sub-tasks do not automatically inherit values from the
parent issue - the exceptions are Fix Version and Component which will inherit if left blank. A project
administrator can define Subtask Templates for various scenarios so that users can select a pre-defined option
and data is populated automatically.
Project administrators can define Subtask Templates for their project from the project administration pages in
JIRA, in the Subtask Templates section. No special request needs to be made.
More information: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-
+Create+Multiple+Subtasks+Quickly

6.7.7 Requesting Structure plug-in be enabled for a project (pilot)

The Structure plugin allows users to define and work with a hierarchy of folders and issues. This is useful for
organizing large backlogs and large projects. Enabling Structure for a project will allow issues from the project to
be added to a Structure. Viewing issues in the project will also show any Structure the issue has been added to.
To request, submit a ticket to IT and ask for Structure to be enabled, and provide your project name and key. If
you are interested in experimenting to check if Structures would be helpful or not, you can also ask to use
Structure in a test JIRA environment first.
Pilot: Enabling Structure on a large, frequently used JIRA project can impact system performance. The plugin is
still in a controlled rollout and being monitored to ensure stability. Depending on the metrics for your project, the
request to enable Structure in the production environment for your project may be rejected. Additionally, because
the plugin is still in a tryout phase, there are no internal best practice guides available yet to help with using this
feature.
More information: https://jira.opentext.com/secure/StructureGettingStarted.jspa

6.7.8 Enabling Microsoft Teams integration for a project (pilot)

A JIRA project can be integrated with a team space in Microsoft Teams. This allows events from JIRA to be
viewed from within MS Teams. These events are currently enabled:
• Issue created
• Issue updated

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 43 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

• Comment created
It is a two-step process to enable. First, from your Team in Microsoft Teams, go to General and the Connectors
menu. Press the Add button for the JIRA connector, give it a name, and press Create. Next, copy the Webhook
URL to the clipboard. Second, submit a ticket to IT and provide (a) the name of the Microsoft team board, (b) the
Webhook URL, and (c) the JQL defining the scope of issues in JIRA to expose in the team board, typically a
Project and a Fix Version, example: Project = "ZRDTT" and FixVersion = "3.0"
Pilot: enabling this integration is still in a controlled rollout. Depending on the metrics for your project, the request
to enable the Teams integration for your project may be rejected.
More information: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-+JIRA+issues+in+Microsoft+Teams

6.7.9 Using the JIRA REST API

The JIRA REST API can be used to add, edit or view issues without accessing the user interface. Any
implementation using the JIRA REST API must be reviewed with both a business and technical approval.
Additionally, the API implementation must be tested using a test environment before connecting to the production
system.
To request a review and a test environment, create an “Enhancement Request” for JIRA using OpenText Self-
Service.

6.7.10 Defining Field Templates

Project administrators can define one or more field templates for any text fields to encourage reporters to provide
a standard set of information in a standard format when creating an issue. Any field templates that are expected
to be used by other groups, such as Customer Support, should be defined in collaboration with those groups.
Templates should only be defined for the Create screen to prevent users from accidentally overwriting existing
field content with a template.
More information: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-+Field+Template

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 44 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Appendix: Customer Support

Additional help content for Customer Support staff, including examples of how to create an issue in JIRA, is available
within the Customer Support section of OpenText University.
Customer Support creates Bugs, Feature Requests, Support Requests and Escalations-Subs.
• Before logging a bug or feature request, perform a search to determine if the issue has already been reported by
another customer. If it already exists then link to the existing issue instead of creating a new one.. If it’s unclear
whether an issue is the same then log a new issue and then add a Comment with a reference to the ID of the
similar issue found.
• Before logging a new bug, try to replicate the issue. It will not always be possible since sometimes a problem will
be intermittent or require a certain set of criteria that are not possible to recreate in a test environment, however
replicating the steps will ensure that Support clearly understands what is happening. Support should be able to
clearly articulate what the customer is trying to do, and what is happening that stops them from being able to
accomplish that. If there is any doubt, the Support rep should engage SME’s within Support to get a second
opinion. Sharing of logs outlining the issue that impairs or prevents functions of the product should be captured if
available.
• If there is doubt whether it’s a bug or a problem caused by environment or configuration issues, then a Support
Request should be logged instead of a Bug. However, if Support is confident that it is a product defect then a Bug
should be logged, even when it cannot be reproduced. Support must include what steps they have tried to
reproduce it and explain why they believe it is a bug. If an investigation of a Support Request reveals the
customer issue is caused by a bug or is a feature request, then Engineering should close the Support Request
and create a new Bug or Feature Request.
• Confidential customer information must not be added to JIRA. This includes any sensitive information whose
access is subject to restriction, including both personal and private information about an individual as well as
confidential information pertaining to a business. Instead, store the information in a document repository with
records management capabilities and only grant permissions to the people who need access and then add a link
to this location to the JIRA issue.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 45 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

JIRA – ServiceNow integration

JIRA issues are represented in ServiceNow as External Task records of task type Jira Record. Multiple cases can be
linked to a single JIRA issue by all linking to the same external task. A single knowledge article can be linked to a
JIRA issue which also relies on an external task.
Creating a new JIRA record from ServiceNow
Creating a new Bug, Feature Request or Support Request in JIRA for Engineering should be created from
ServiceNow, using the “New Jira record” function from the External Tasks of the case. This will create a new issue in
JIRA and a new external task in ServiceNow that links the case to the new JIRA issue.

Request Type Bug – a product defect where the product is not behaving as expected
Feature Request – a request for a new feature, enhancement or change in expected behavior
Support Request – a formal request to Engineering to assist on a case

Project The project key in JIRA used for reporting new issues for the product

Affects Build The full version the customer is running, including any patch level
(Engineering will use the value to populate the Affects Version field in JIRA.)

Environment The details (e.g. operating system, database, web browser, on-prem, third-party cloud, etc) of the customer
environment needed to reproduce or understand the issue.

Summary Short summary of the issue. It is important that this field be as clear and concise as possible. Do not simply re-
use the case short description from the customer, use your own words based on your current understanding of
the issue.

Description A description of the problem or request. Do not simply re-use the case description from the customer.
The description must contain the following information:
1. Steps to reproduce.
2. What happened/what did you observe
3. What did you expect to happen?

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 46 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

The Description should be used to define and clarify the issue and steps that have already been taken to
investigate. It should be detailed enough that Engineering does not need to ask questions to fully understand the
issue. If the Engineering product team has defined a standard template or set of questions to be answered then
this should be referenced to properly populate the Description.

Urgency This should be auto-populated from the Case based on the Impact and Urgency, but you can adjust as needed.
The options are: P1, P2, P3, P4 where P1 is the most urgent.
The actual severity of the bug. The options are Blocker, Critical, Major, Minor and Trivial.
Jira Priority
The default is Undefined.
See the Prioritization section in the document for more information.
Setting to Blocker or Critical triggers special attention and should only be used as defined.

• When the issue is created in JIRA from ServiceNow, the ServiceNow ID field in JIRA is populated with the ID of
the external task in ServiceNow. The Ticket_PTS_Number in JIRA is populated with the case number and
CustomerName is populated with the account name.
• Updates made in JIRA will synch to the external task. This includes the fields entered by Customer Support as
well as: Status, Resolution, Fix Version, Assignee
• Any comments added in JIRA by Engineering will appear as Work Notes on the External Task in ServiceNow, and
any work notes added in ServiceNow by Customer Support will appear as comments on the issues in JIRA.
• If an issue is created directly in JIRA instead of creating from ServiceNow, you must then perform a second step
to link the case to the JIRA. A Jira issue cannot be linked to a case from the JIRA interface, a case must be
linked to a Jira issue from ServiceNow.
• Adding attachments (screenshots, log files) to the external task will add them to the JIRA issue. If an attachment
is too large or contains confidential info, then Support should place in a share where development has access and
add a work note with the link. Confidential customer information must not be stored in JIRA
Linking to an existing JIRA
If a search reveals that the same bug or feature request has already been logged in JIRA then the case should be linked
to the existing issue.
• The External Task Jira record should already exist in ServiceNow and the JIRA issue will have the ServiceNow ID
populated with the ID of the external task, From the case in ServiceNow, open the External Tasks on the case
and use the “Add” feature. You can filter by either External ID (the JIRA ID) or External Task Number
(ServiceNow ID) to find and link the external task.
• If the JIRA issue already exists but there is no External Task record yet in ServiceNow, then use the New Jira
Record function from External Tasks and then the “Link JIRA Issue” option and enter the JIRA ID to create the
external task for an existing JIRA. If it’s not automatically linked to the case then manually add the new external
task to the case.
• When a case is linked to an existing issue in JIRA, the issue in JIRA is automatically updated.
o The Ticket_PTS_Number field is updated with all linked case numbers, separated by spaces
o The CustomerName field is updated with all linked account names, separated by semi-colons
o The Reported Count field is updated with a count of cases linked to the external task
Knowledge Articles
• For confirmed new bugs, Customer Support will create a knowledge article on My Support when appropriate. If a
knowledge article is created, the JIRA ID must be entered in the Tracking Number of the article. Once the article
is published this will set the “ServiceNow KBA” field on the JIRA issue.
o Linking a knowledge article to a JIRA ID will create the external task if it does not already exist, or will
automatically re-use if it was already created previously for the JIRA.
• Only a single knowledge article can be created for each JIRA issue. Attempting to create a second knowledge
article using the same Jira issue will error.
• When the JIRA issue is closed, it will automatically generate a follow-up task in ServiceNow for the article’s
ownership group to update the article.
• Engineering should try to be aware whenever the ServiceNow KBA field has been populated on a JIRA issue and

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 47 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

therefore an article has been published about it. Whenever updates should be made to an article, Engineering
can provide feedback on the article in ServiceNow using the feature “Is this article helpful > No” and submit the
reason and details.

Escalations
Customer Support also officially escalates issues to development using JIRA. Typically, only certain individuals in
customer support are authorized to officially escalate an issue to development and so approval must be received from the
appropriate Level 3 (L3) staff or Support manager first.
The process to escalate an issue is to create an Escalation-Sub task in JIRA under the issue. An Escalation-Sub cannot
be created from ServiceNow and must be created using the JIRA interface.
• if the escalation is related to a bug or feature request and the issue has not already been created in JIRA, then
first create the Bug or Feature Request.
• Once it exists, create a sub-task on the issue of type “Escalation-Sub” directly in JIRA. An Escalation-Sub is most
commonly used to request a hot fix but can also be used to flag any JIRA issue that needs to be escalated. Do
not link to an existing Escalation-Sub, always create a new Escalation-Sub. Escalations are created as sub-tasks
because a single issue can have multiple escalations from multiple customers at the same time that need to be
tracked separately, and it’s also possible to resolve an escalation by providing a workaround or other solution
without resolving the parent issue.
• In the Escalation-sub, fill out the fields as defined in the issue type definition section, include the customer name
and version information that is relevant for the escalation and enter details about why it’s being escalated and the
customer expectations for a response in the Description field.
• if the escalation situation is not related to a confirmed bug or feature request and is a request for information or
assistance with an investigation, then create an issue in the project of type “Support Request” from ServiceNow.
• Once the issue is created, an email is optionally also sent to the pre-agreed contacts for the product to inform all
of them about the new escalation. While email is typically used to manage communications for an escalation, the
JIRA issue must always be updated with any information needed to understand the escalation and its history.
• Development will review Blocker and Critical issues within 4 hours of notification based on normal business hours
• Critical and Blocker issues are expected to be resolved within 30 calendar days (one month)
• Teams should have a regular escalation review meeting to review progress and prioritize all current escalations.
This can be combined with the triage meeting when practical.
• Red/Yellow Escalations are defined by customer support and reviewed with Senior Leadership once a week in the
Red/Yellow meeting.

Triage SLA
All new issues are reviewed in a regular triage meeting with customer support representatives where the triage category is
reviewed. Any “Watchers” will get email notifications on updates to the issue. This can be used to determine when an
issue has been scheduled or fixed which can be communicated back to the customer. Customer Support can enable the
Auto-Watch profile preference to be automatically added as a Watcher to every issue they create.
The Triage Service Level Agreement (SLA) between Engineering and Customer Support defines the following two rules
for new customer reported issues:
• Development will review Blocker and Critical issues within 4 hours of notification based on normal business hours
• All other issues will be reviewed within 7 calendar days (one week)
An issue is considered triaged once
• the Priority has been reviewed and set
• the issue has been assigned to a Fix Version value that fits one of the four categories of:
o Scheduled to a Release Version (actual version release or service pack name)
o Backlog Version (on short list, pending scheduling in next 3-6 months)
o No Plan Version (not on roadmap)
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 48 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

o Hot Fix Version (scheduled to a one-off hot fix)

• or the issue has been closed
It is the responsibility of the Product Manager to triage customer issues, however this responsibility can be delegated if it
is agreed.
All new issues must be reviewed within one week and should be triaged in that timeframe. However, it is understood that
some complex issues may require additional follow-up and investigation and will sometimes take more than a month to
complete the triage process.
There should be a weekly triage meeting with the product manager and representatives from development and customer
support. The meeting should review all new issues from the past week, plus any untriaged issues from previous weeks.
Teams with a high volume of new issues may choose to meet more frequently, while teams with a very low volume can
choose to meet less frequently or not at all.
The suggested filter criteria for new issues and untriaged issues logged by customer support is: Project = “Key” AND
"CustomerName" is not empty AND (created >= -1w OR FixVersion is empty). The suggested filter name is Product
Name + “Triage Meeting”.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 49 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Appendix: Engineering Quality Dashboard

The Engineering Quality Dashboard provides common metrics for customer-reported bugs giving a picture of product
quality and responsiveness.
Link https://eng-dashboard.opentext.com
Each week, teams and managers should check the dashboard to monitor their products.
• Quality: The Backlog metrics show the number and trend of customer-reported bugs. Products with a low number
of bugs are expected to keep it low. Products with a high number of bugs are expected to keep trending lower
over time.
• Responsiveness: The SLA metrics show compliance to the Service Level Agreements agreed to with Customer
Support: resolving Blocker/Critical customer bugs within 30 calendar days; and triaging all new customer bugs
(setting the fix version) within 7 calendar days. Business Units are expected to achieve 90% or higher
compliance each month for both, and ensure any issue that has violated an SLA is identified and there is a plan to
address it.
The dashboard has a three-level hierarchy of: Business Unit, Product Line, and JIRA Project. To make updates to the
product mapping or to exclude a project with no customer-reported issues from the dashboard, the project administrator
can update the OpenText Product project setting. To request updates or corrections to the hierarchy mapping, a manager
should send an email a ticket to ERPHT@opentext.com.

Appendix: Traceability Matrix

The Traceability Matrix is a custom report that show a hierarchy view of related issues and their status. It can be used to
report on project status or to verify all issues in a project scope have been fully completed and closed. The parent/child
relationships are based on the Details/Is Detailed By links, Epic Links, and Sub-tasks.
Link: https://confluence.opentext.com/display/OTPD/JIRA+Traceability+Matrix
The report has three options:
• Based on Project + Fix Version (recommended)
• Based on Issue Key (a single root issue)
• Based on AgileBoard (only includes issues assigned to a sprint)
The report can be saved to PDF and then added to the project folder in Ollie.

Appendix: Reporting Database

A read-only copy of the JIRA database is available for teams that want direct access for reporting.
In addition, there are two Excel Reporting templates with pre-defined connections and queries that can be edited.
For more information: https://confluence.opentext.com/display/RDOT/JIRA+Tips+-+Reporting+Database+for+JIRA

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 50 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Appendix: Watcher Notification Scheme

The following table defines the Watcher Notification Scheme that is used for all new projects. Project Administrators for
older projects with a different scheme can ask for their project to be updated to this one by submitting a ticket to IT.
Project Project Watchers Component Reporter Current Issue
Action
Admins Watchers CreateOnly Watchers Assignee Watchers
Created x x x x x x
Updated x x x x
Assigned x x x x
Resolved x x x x
Closed x x x x x
Comment x x x x
Comment
edited
Reopened x x x x
Moved x x x x x x
Progress
x x x x
Start/Stop
Work Logged
Log updated
Other Events x x x x

Note: the Project Lead and Component Leads have no automatic email notifications with this scheme.
Users can also configure two profile preferences that affect their email notifications:
• My Changes: whether to receive notifications for changes you make yourself. Default is do not notify.
• Autowatch: whether to be automatically added as a Watcher for every issue you create or comment on. Default is
disabled.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 51 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Appendix: Permissions Scheme

The following table defines the permission scheme that is used for all projects. Most issue actions can be performed by
any user for any issue in any project.
Project Project Project Issue All
Action Lead Admins Team Reporter Users
Members
Create Issue x x x x x
Edit Issue x x x x x
Link x x x x x
Transition Status x x x x x
Reopen from Closed * x x x
Schedule Issue
x x x x x
(set Due Date, Sprint)
Assign Issue x x x x x
Assignable User (A) x x x x x
Assignable User (B) x x x x
Modify Reporter x x x x
Manage Issue Watchers x x x x
Comment, edit own x x x x x
Edit other user’s comment x x
Add Attachment, delete own x x x x x
Delete other’s attachment x x
Move Issue * x x x
Delete Issue
Project Actions
Edit Details (Name, Avatar) x x
Manage Roles x x
Manage Versions x x
Manage Components x x
Manage Sprints x x x x x
Reopen from Closed: once an issue has been Closed, it cannot be re-opened by any user. Only the reporter of the issue
or a member of the project can re-open it. This is a workflow restriction to prevent very old issues from being incorrectly
re-opened since this can dramatically affect certain Engineering metrics, like Time-to-Resolve.
Assignable User: by default, an issue can be assigned to any user (A). However, this makes the auto-complete slower
to use. Project Administrators can ask for their project to be switched to an alternate scheme (B) where an issue can only
be assigned to a member of the project or back to the Reporter. To make this change, submit a ticket to IT, provide the
project name and key, and ask for the “Assignee-Developer” scheme.
Move Issue: Moving an issue to another project removes the issue from the current project and regenerates the issue ID
each time. So because it is not a fully reversible action it is not available to all users. However, the “Move” permission is
also required to change the issue type to or from UserStory so is also restricted the same way.
Manage Sprints: To reduce the risk of permission errors caused by issue moved between projects, any user can start
and manage sprints. However, the filter for a board must include criteria that explicitly defines the list of projects being
included. If this is missing, access to all projects in the system is needed and, because of the existence of special
restricted projects this won’t be true and the sprint actions for the board will fail.
:
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 52 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

Exception Handling
If a situation arises that requires deviation from an approved SOP, an email should be sent to
qualitymanagement@opentext.com indicating the deviation, SOP, and reason for deviation.

Approval
The following approvals are required for this document:
Agile PMO Program Manager
Management Representative of the PDS or designate
As of the effective date this procedure is the standard and supersedes any previous versions.

REVISION HISTORY

Rev# Date Author Description

1.0 16-Nov-2011 Jacey Kennedy Original

1.1 27-Feb-2012 Jacey Kennedy Edit to Roles : “Developers” has been renamed to “Team Members”
Incorporated feedback from QA, Documentation, Security, Development, Agile Coaching
team
Incorporated feedback from Agile PMO Program Manager (aka Brad)

1.2 26-Nov-2012 Brad McIlmoyl Added Globalization Type

1.3 05-Apr-2013 Brad McIlmoyl Priority definitions edited to incorporate feedback from User Design team, with related
changes to the Ordering and Security Defect sections.
New Team field described in Assigning section.
New permission associated with Team Members role.

1.4 15-Apr-2013 Brad McIlmoyl Minor updates to address notes in previous version.

2.0 21-Oct-2013 Brad McIlmoyl Numerous changes to reflect new JIRA Agile plugin (Greenhopper)
Numerous changes to merge the Triage SOP.

2.1 7-Mar-2014 Brad McIlmoyl Added new workflow statuses (To Do, Verified), new issue types (Doc Task, Localize
Task) and new fields (Release Note, Test Information).

2.2 3-Jun-2014 Brad McIlmoyl Priority definitions edited to incorporate feedback from Performance team.

2.3 9-Jan-2015 Brad McIlmoyl Added definitions for the six new fields added since the last update: Flagged, Urgency, PM
Commitment, Release Timebox, Investment Theme, PCR Number, Billing Project. All
except Flagged were added to support the GXS migration,

2.4 19-Feb-2015 Brad McIlmoyl Added new Resolution option Unsupported Environment

2.5 2-Apr-2015 Brad McIlmoyl Updated Agile Boards section to reflect the new terminology in JIRA 6.

2.6 29-Oct-2015 Tim McCrabb Updated rules in Security Severity Level section.

2.7 5-Feb-2016 Brad McIlmoyl Updated Bug creation to reflect new ITSM Severity field that corresponds to JIRA Priority
field.
Updated 30 day SLA references to consistently use “resolved”.

2.8 19-Aug-2016 Brad McIlmoyl Delimiter for Customer Name field updated from comma to semi-colon.
Added the rule for Start Progress that unassigned issues will be automatically assigned.

2.9 02-Sep-2016 Brad McIlmoyl Minor update for semicolons

2.10 30-Sep-2016 Brad McIlmoyl Added new “Done” resolution.

Added rule that Fix Version is enforced as mandatory when resolving as “Fixed”.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 53 of 54
 Issue Management using JIRA Version 2.22.0
SOP-00344 (Standard Operating Procedure) 14-Oct-2022

REVISION HISTORY

Rev# Date Author Description

2.11 10-Apr-2017 Brad McIlmoyl Added missing process for requesting new user account
Added new “Defect Sub-task” issue type
Added new “Review” status
Added information for new Structures object
Updated process for requesting new JIRA project
Added missing Watchers role; Product Owner role was deprecated
Added appendices for Notification and Permissions schemes as a reference
Other minor edits for clarity

2.12 24-Oct-2017 Tim McCrabb Changes to Sections 3.2/3.3.

Changes around Rules for Blocker, Critical, and Major Priority issues.
Changes to adhere to Global Information Security remediation timelines.
Inclusion of guidelines around how to classify a vulnerability by its Security Severity Level,
using industry standard best practice CVSS guides and calculators.

2.13 4-Jan-2018 Brad McIlmoyl Added new CVSS Level field for Security Issues

2.14 21-Jun-2018 Brad McIlmoyl Added new WatchersCreateOnly role to appendix

Updated text for Localize task
Add new section for special system requests
Added new appendix for Quality Dashboard, Traceability Matrix and Reporting

2.15 08-Feb-2019 Brad McIlmoyl Added section for submitting a JIRA ticket to IT
Updated explanation for Kanban board for JIRA 7.13

2.15.1 16-Apr-2020 Brad McIlmoyl Added new OpenText product section for project administration
Fixed several mistakes: IT help links, SAP references, Permissions appendix

2.15.2 17-Apr-2020 Brad McIlmoyl Fixed format issue

2.15.3 29-Oct-2020 Brad McIlmoyl Added new T-Shirt Size field for use with Epics
Added new Documents link type for use with Doc Task
Clarified scenarios related to IT Tickets

2.16.0 25-Mar-2021 Brad McIlmoyl Added more details for customer support scenarios, including the handling of Support
Requests and escalations
Added process for Field Templates and setting Users role
Stricter naming convention for Fix Versions

2.16.1 16-Apr-2021 Brad McIlmoyl Updated Field Templates process to reflect enhancements in new version

2.16.2 12-Jul-2021 Brad McIlmoyl Added Blocked and QA In Progress workflow status (Webroot)
Added Discovery field for logging Security issues
Removed Create-and-link

2.17.0 13-Aug-2021 Brad McIlmoyl Added Dependencies section

Updated link to Quality Dashboard

2.18.0 01-Apr-2022 Brad McIlmoyl Added rule prohibiting storing confidential information in JIRA
Updated Watchers Notification Scheme

2.19.0 27-Apr-2022 Brad McIlmoyl Added Documentation Required field and action
New rule that Doc Task is only for tasks that will be assigned to PI team

2.20.0 22-Jun-2022 Brad McIlmoyl Added Roadmap issue type

2.21.0 06-Sep-2022 Brad McIlmoyl Updated with changes for ServiceNow replacing ITSM
CAPA-762

2.22.0 06-10-2022 Brad McIlmoyl New Security Severity Level “Critical”

CAPA-767

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 54 of 54