Jira Ticket Management Operating Standard

Table of Contents

Order	Area	Governance Focus	Expected Outcome
1	Introduction and Strategic Objective	Establish the purpose, operating discipline, and documentation expectation for Jira-driven work.	Jira remains the common record for requirements, decisions, evidence, approvals, and closure.
2	Jira Classification Standards	Define the correct Jira project and ticket type before work enters planning or assignment.	Tickets are raised in the correct project and classified as Story, Support, Bug, or Question.
3	Ticket Requirements and Workflow Rules	Standardise intake details, reviewer checks, workflow gates, evidence requirements, and closure rules.	Each ticket moves forward only with the required context, ownership, approval, and validation trail.
4	Planning and Prioritisation	Control weekly planning, readiness checks, clarification timelines, priority swaps, and status hygiene.	Planned and urgent work remains visible, justified, owned, and traceable.
5	Specification and Template Standards	Define document storage, specification usage, test case linkage, and template selection rules.	Teams use consistent documentation standards across projects and ticket types.

1. Introduction and Strategic Objective

1.1 Purpose

This operating standard defines the common process for raising, classifying, reviewing, progressing, approving, and closing Jira tickets across DH implementation, product, application, and Data Manager work.

The standard ensures that every requirement, support request, defect, clarification, decision, approval, test outcome, RCA, and release action is recorded in Jira or in a linked controlled document. Jira must remain the official system of record for work intake, execution tracking, ownership, and closure.

1.2 Scope

This SOP applies to Jira tickets raised under the following work areas:

Work Area	Coverage
Client Implementation	Client-specific requirements, configuration, extraction, stream setup, UAT support, production support, and movement activities.
DH Product Development	Product binaries, product-level enhancements, and product defect fixes.
DH Application	Application screens, UI behavior, application support, application defects, and application enhancements.
Data Manager	Data Manager screens, UI behavior, DM application support, DM application defects, and DM application enhancements.

1.3 Strategic Objective

The objective of this SOP is to improve planning discipline, ticket quality, delivery traceability, and closure control by standardising how work is classified and progressed in Jira.

Objective Area	Standard Outcome
Work intake quality	Tickets are raised with all the information required for triage, planning, assignment, and review.
Classification accuracy	Each ticket is raised under the correct Jira project and classified as Story, Support, Bug, or Question before work begins.
Planning readiness	Weekly and mid-week planning decisions are based on clear scope, priority, evidence, owner, and dependency information.
Requirement clarity	Functional specifications, assumptions, expected outputs, test expectations, and approval requirements are documented before development starts.
Support control	Runtime failures, data issues, configuration issues, and production concerns are investigated with logs, evidence, impact, and RCA trail.
Defect discipline	Bugs are raised only when implemented behavior deviates from an approved Story, specification, or accepted test case.
Ownership visibility	Current owner, pending action, blocker, approver, and next step remain visible in Jira throughout the ticket lifecycle.
Audit readiness	Decisions, approvals, test evidence, release evidence, RCA, and closure comments remain traceable for future review.

1.4 Operating Principles

Principle	Required Practice
Jira is the source of truth	Decisions, clarifications, approvals, status movements, and closure evidence must be posted in Jira or linked from Jira.
Classification comes first	Project and ticket type must be confirmed before the ticket enters active planning or assignment.
Evidence drives progress	Tickets should not move forward on verbal context alone; required documents, logs, samples, approvals, or test evidence must be linked.
Scope must remain controlled	Any new requirement, change in expected behavior, or post-release issue must be raised through the correct ticket path.
Closure must be defensible	A ticket should be closed only after the outcome, validation evidence, and final decision are documented.

2. Jira Classification Standards

2.1 Classification Model

Jira classification must be completed before a ticket is accepted for planning, assignment, or execution. Classification is not only an administrative step; it determines ownership, approval path, workflow, evidence requirement, and closure standard.

Classification Layer	Question to Answer	Control Objective
Project	Where should the work be tracked?	Route the ticket to the correct ownership, planning, approval, and release path.
Ticket type	What kind of work is being requested?	Apply the correct intake, review, workflow, evidence, and closure standard.

A ticket must not be classified only by urgency, requester preference, or expected assignee. The classification must reflect the actual nature of the work.

2.2 Project Routing

Project	Classification Standard	Jira Client Field
DHIMPL	Use for client-specific implementation, configuration, extraction, stream setup, UAT support, production support, movement, or client environment work.	Actual client name
DHPROD	Use for core DH product binaries, product logic, product enhancements, product defects, and product release work.	SURYA INTERNAL
DHAPP	Use for DH RunControl Web Application screens, UI behavior, application support, application defects, and enhancements.	Actual client name for client-specific work; SURYA INTERNAL for product-level work
DM	Use for Data Manager rules, rule changes, configuration, execution support, failures, reconciliation, output investigation, or enhancements.	Actual client name for client-specific work; SURYA INTERNAL for product-level work

2.3 Ticket Type Routing

Ticket Type	Classification Standard	Typical Outcome
Story	Use when planned work or approved change is required.	Scope is reviewed, approved, developed, tested, released, and closed.
Support	Use when an existing operational issue needs investigation or assistance.	RCA, action taken, and validation result are documented.
Bug	Use when approved behavior is not working as documented, tested, or released.	Defect is corrected, regression is validated, and release/closure evidence is recorded.
Question	Use when clarification is required before execution can proceed.	Answer or decision is documented; follow-up Story, Support, or Bug is linked if work is required.

2.4 Classification Decision Guide

If the Request Is About	Raise As
New development, enhancement, setup, movement, extraction, AutoSys, or configuration change	Story
Run failure, scheduler issue, configuration issue, production support, UAT support, or RCA request	Support
Mismatch against an approved Story, functional specification, accepted test case, or released behavior	Bug
Feature availability, expected behavior, configuration doubt, feasibility, ownership, or correct ticket path	Question

2.5 Classification Acceptance Check

A ticket is classification-ready only when the following points are clear.

Readiness Item	Acceptance Standard
Project	The ticket is raised under the correct Jira project: DHIMPL, DHPROD, DHAPP, or DM.
Ticket type	The ticket type correctly reflects the request: Story, Support, Bug, or Question.
Client value	The client field follows the project standard: actual client name or SURYA INTERNAL.
Context	The ticket clearly states the requirement, issue, defect, or clarification needed.
Evidence	Required documents, logs, screenshots, samples, specifications, or test references are attached or linked where applicable.

2.6 Reclassification Rules

When review confirms that the original ticket type is no longer correct, the required follow-up ticket must be raised or linked by the responsible BSA/Support owner. Work must continue under the workflow rules of the newly classified ticket type, not under the original ticket by exception.

Situation Identified During Review	Required Action
Support investigation confirms that a permanent change is required.	BSA/Support must raise or link a Story.
Support investigation confirms that approved behavior is broken.	BSA/Support must raise or link a Bug with the supporting investigation evidence.
Bug review confirms that the expected behavior was not approved or documented.	BSA must stop the defect path and raise or link a Story if a change is required, or a Question if clarification is required.
Question response confirms that execution work is required.	BSA/Support must raise or link the appropriate Story, Support, or Bug.

3. Ticket Requirements and Workflow Rules

3.1 Story

A Story is used for planned delivery. It may represent new development, enhancement, setup, movement, extraction, AutoSys work, configuration change, or production movement.

3.1.1 Story Intake Requirements

Requirement	Mandatory Standard
Client	Use the actual client name for client-specific work. Use SURYA INTERNAL for product-level work.
Jira summary	Provide a clear summary of the requirement or change.
Description	Explain what is needed, why it is needed, and what business/regulatory/operational driver applies.
Functional specification	Attach the link to the approved/reviewable functional specification stored in the OneDrive ticket folder.
Input details	Document source files, tables, fields, formats, filters, dates, record-count expectations, and sample data where applicable.
Output details	Document output files, reports, fields, derivations, formats, grouping keys, reconciliation expectations, and sample expected output where applicable.
Business logic	Define calculation rules, mapping rules, conditions, defaults, validations, exceptions, and fallback behavior.
Test expectations	Provide positive scenarios, negative scenarios, edge cases, reconciliation checks, regression scenarios, and volume scenarios where applicable.
Impact and dependency	Identify impacted binaries, streams, reports, extractions, application screens, and release dependencies.
Approval path	Identify required BSA, Product Lead, Client Lead, PCC, or other approval before development/release where applicable.
Target timeline	Mention expected delivery date, client commitment, or planning priority where applicable.

3.1.2 Story Review Responsibilities

Role	Responsibility
Reporter	Ensure the requirement, scope, functional specification, assumptions, approvals, and test expectations are complete before BSA acceptance.
Product/Client Lead	Confirm approval on the details shared by the Reporter.
Dev reviewer	Review feasibility, missing details, data availability, edge cases, performance impact, configuration impact, and regression scope before dev acceptance.
Implementer	Develop only the approved scope and raise Jira clarification before implementing any undocumented behavior.
Code reviewer	Review logic, regression risk, error handling, logs, validation, and maintainability before code review closure.

3.1.3 Story Workflow Gates

Workflow Gate	Required Control
Func. Spec. Accepted by BSA	Only the authorized Lead BSA or Client Lead BSA may move the ticket to this status.
Func. Spec. Accepted by Dev	Dev reviewer must confirm feasibility and raise all open clarifications in Jira before accepting.
Before release	Release notes, package details, and deployment instructions must be provided by the Developer in Jira and GitHub as per the Development Guideline.

3.1.4 Story Acceptance Authority

Change Type	Authorized BSA Acceptance
Product-level change under DHPROD, DHAPP, or DM	Product Lead BSA as applicable.
Client-specific change under DHIMPL	Client Lead BSA.
Change impacting PCC or product release	PCC approval must be provided in Jira, and Dev Owners must be part of PCC discussions and email communication.

3.1.5 Story Reopen and Follow-up Rule

Once a Story has been moved to Production or marked Stable by BSA, it must not be reopened for new work or post-release correction.

Post-release Situation	Required Action
Approved functionality fails after release	Raise a new Bug and link the released Story.
Additional requirement or behavior change is requested	Raise a new Story and link the original Story.
Clarification is needed on released behavior	Raise or link a Question before creating executable work.

3.2 Support

A Support ticket is used for operational assistance, run investigation, RCA, configuration issue, or production/UAT support. Support is not a substitute for planned development or defect correction.

3.2.1 Support Intake Requirements

Requirement	Mandatory Standard
Client	Use the actual client name for client-specific support. Use SURYA INTERNAL for product-level support.
Issue summary	State what failed, what is blocked, or what assistance is required.
Environment	Mention SIT, UAT, Production, server, region, client environment, or application environment where applicable.
Process details	Provide stream name, process name, batch/binary name, run ID, process ID, as-on date, execution date/time, and scheduler/job details where applicable.
Error evidence	Attach logs, diagnostic logs, console output, application logs, scheduler logs, screenshots, or exception details.
Data evidence	Attach input files, output files, rejected records, count comparison, sample records, DB query output, or reconciliation sheet where applicable.
Configuration evidence	Provide config path, metadata values, parameter values, connection details, AutoSys/job configuration, or deployment details where relevant.
Expected vs actual	Required when output, data, behavior, or status does not match expectation.
Business impact	Mention blocked run, delayed delivery, missing output, wrong output, downstream impact, production impact, or client commitment.
Action requested	Clearly state whether analysis, RCA, setup correction, validation, explanation, deployment coordination, or confirmation is required.

3.2.2 Support Review Responsibilities

Role	Responsibility
BSA/Support owner	Confirm support scope, collect maximum evidence, document business impact, and coordinate closure validation.
Dev reviewer	Review logs/config/data evidence to proceed with investigations.
Developer	Identify probable cause and provide RCA in Jira.

3.2.3 Support Workflow Controls

Workflow Point	Required Control
Before investigation	Logs, environment, run details, action requested, and impact must be available.
During investigation	RCA progress, observations, assumptions, missing evidence, and next actions must be updated in Jira.
If permanent change is required	BSA/Support must create or link a Story. Development must not continue only inside the Support ticket.
If approved behavior is broken	BSA/Support must create or link a Bug with supporting evidence.
Before closure	RCA, action taken, validation result, and follow-up tickets must be documented.

3.2.4 Support Closure Outcomes

Closure Outcome	Required Closure Note
Issue resolved without change	RCA, corrective action, and validation evidence.
Data/config/environment issue	Root cause, corrected value/path/setup, owner of correction, and validation evidence.
Permanent change required	Linked Story with summary of required change.
Approved behavior broken	Linked Bug with expected-vs-actual evidence.
Not reproducible or insufficient evidence	Evidence reviewed, missing information, and reason for closure or pending state.

3.3 Bug

A Bug is used only when implemented behavior does not match a Story, functional specification, accepted test case, or released behavior. A Bug must have an approved baseline; otherwise the request must be handled as a Story or Question.

3.3.1 Bug Intake Requirements

Requirement	Mandatory Standard
Client	Use the actual client name for client-specific defects. Use SURYA INTERNAL for product-level defects.
Original Story/spec link	Link the approved Story, functional specification, test case, or release reference that defines expected behavior.
Defect summary	State what is not working in clear business or operational terms.
Expected behavior	Document the exact expected output, value, file, status, calculation, validation, or UI behavior from approved evidence.
Actual behavior	Document what actually happened, including output, error, mismatch, failed step, or observed behavior.
Reproduction details	Provide environment, run command/process, input file/table, configuration, as-on date, run ID, and steps to reproduce.
Observation test case	Provide test case ID, test input, expected result, actual result, and failed assertion where applicable.
Evidence	Attach logs, screenshots, output files, DB results, comparison sheets, rejected records, or application evidence.
Impact	Mention affected client, release, production/UAT run, downstream process, regulatory output, or operational delivery.
Priority reason	Explain why the defect is high, medium, or low priority based on impact and timeline.

3.3.2 Bug Validity Checks

Check	Standard
Approved baseline exists	A Bug is valid only when expected behavior is already approved or released.
Expected vs actual is clear	The ticket must show a concrete mismatch, not only a general concern.
Reproduction is possible	Input, config, environment, and steps must be sufficient for review or reproduction.
Requirement gap is excluded	If expected behavior was not approved, the ticket must move to Story or Question.
Environment/data issue is excluded	If the cause is setup, permissions, scheduler, data, or config outside approved behavior, handle through Support unless a defect is confirmed.

3.3.3 Bug Review Responsibilities

Role	Responsibility
BSA/Support owner	Provide expected-vs-actual evidence and link the approved baseline.
Dev reviewer	Validate defect scope, reproducibility, RCA direction, and whether the issue is code, data, config, environment, or requirement gap.
Fix owner	Implement only the approved defect correction and avoid adding unapproved enhancement.
Code reviewer	Review fix logic, regression risk, impacted paths, validations, logging, and error handling.
BSA tester	Validate the fix against the failed scenario and required regression scenarios.

3.3.4 Bug Workflow Gates

Workflow Gate	Required Control
Before defect acceptance	Approved baseline, expected-vs-actual evidence, client value, impact, and reproduction details must be present.
Before fix	RCA direction, failed scenario, fix scope, and regression scope must be clear.
Before code review	Fix details, impacted logic, unit/developer validation, and regression considerations must be available.
Before testing	Build/package details, failed test case, expected output, and regression test cases must be available.
Before release	Fix validation, regression evidence, release package, and required approvals must be linked.
Before closure	Final validation result, release confirmation, and closure summary must be documented.

3.3.5 Bug Reopen and Follow-up Rule

Once a Bug has been moved to Production or marked Stable by BSA, it must not be reopened for additional correction or new behavior.

Post-release Situation	Required Action
Another defect is found after release	Raise a new Bug and link the released Bug.
Requirement change is needed	Raise a new Story and link the original Story.
Expected behavior is disputed	Raise or link a Question before further execution.

3.4 Question

A Question ticket is used when clarification is required before work can be classified, planned, approved, assigned, or executed. It is used to record decisions and prevent work from proceeding on assumptions.

3.4.1 Question Intake Requirements

Requirement	Mandatory Standard
Client	Use the actual client name for client-specific clarification. Use SURYA INTERNAL for product-level clarification.
Exact question	State the question clearly. Use numbered questions if more than one clarification is required.
Context	Mention client, module, binary, stream, application screen, Data Manager rule, configuration, environment, release, or product version where applicable.
Current understanding	Document what the requester currently believes or assumes.
Decision needed	State what answer is required to proceed.
Evidence	Attach screenshots, config snippets, sample files, logs, previous Jira links, or documents where relevant.
Required date	Mention the date/time by which the answer is needed if planning or delivery is blocked.

3.4.2 Question Review Responsibilities

Role	Responsibility
BSA/Support owner	Frame the question clearly, provide context, and link follow-up work if the answer requires execution.
Developer	Provide answer, limitation, feasibility, configuration behavior, or product behavior based on available evidence.

3.4.3 Question Workflow Controls

Workflow Point	Required Control
Before response	Exact question, context, current understanding, and decision needed must be available.
During clarification	Assumptions, dependencies, missing inputs, and reviewer observations must be documented in Jira.
If execution work is required	BSA/Support must create or link Story, Support, or Bug based on the answer.
Before closure	Final answer, decision, limitation, next action, or linked follow-up ticket must be documented.

3.4.4 Question Closure Outcomes

Closure Outcome	Required Closure Note
Answer provided	Final answer, assumptions, and evidence used.
Story required	Linked Story and summary of approved/required change.
Support required	Linked Support ticket and reason investigation is needed.
Bug identified	Linked Bug and expected-vs-actual basis.

4. Planning and Prioritisation

Planning must be based on ticket readiness, business impact, priority, dependency, and ownership. A ticket should not enter active planning only because it is urgent; it must first have the minimum information required for its ticket type.

4.1 Weekly Planning Rules

Planning Control	Standard
Ticket availability	The ticket should be accepted by Lead BSA on or before Wednesday so it can be reviewed for the upcoming weekly plan.
Classification	The Jira project and ticket type must be checked before the ticket is raised.
Readiness	The ticket must contain the minimum intake details, context, and evidences required for its ticket type.
Dev reviewer clarification timeline	Once Lead BSA acceptance is provided, the Dev Reviewer must review the ticket and raise any required clarification within 2 working days.
Clarification closure	Open clarifications raised by Dev Reviewer should be resolved before Friday first half wherever possible.
Priority basis	Priority must be supported by business impact, release timeline, client commitment, production impact, or product dependency by the BSAs.
Mid-week priority	Any mid-week priority must state which existing planned item is swapped or pushed.
Reclassified tickets	Reclassified tickets must go through the planning process under the new ticket type. They must not bypass planning or be taken up through the original ticket.
Status hygiene	Jira status and latest comments must reflect actual progress, blocker, owner, and next action.

4.2 Priority and Swap Rules

Priority Situation	Required Action
Planned weekly work	Weekly planning is prioritised based on readiness, business impact, release date, client commitment, production impact, and dependency.
Swap between planned tickets	If BSA wants to swap one existing planned ticket with another existing planned ticket, it is BSA's responsibility to discuss the change and provide the swap ticket details in Jira.
Mid-week new requirement	Once the ticket meets the acceptance criteria, BSA must review the effort shared by the Dev Reviewer and provide the ticket to be swapped, delayed, or retained for planning.
Priority collision	BSA/Support must identify the impacted ticket and document the swap, delay, or retained commitment in Jira.
Production issue	Production issues must receive the highest priority once the required details are clear. The Dev Reviewer must confirm that the issue details are sufficient to proceed and Dev Reviewer should plan it.
Release date and client commitment	BSA must consider that release dates are planned 2 days after the due date. Client commitments must be communicated and planned with this release gap.

4.3 Status Update Rules

Status Control	Standard
Actual progress	Jira status must reflect actual progress, not expected progress.
Comment discipline	Every material status movement must have a Jira comment or linked evidence.
Owner clarity	Tickets must not remain active without a current owner, blocker, or next action.
Decision trail	Decisions taken over call, chat, or email must be summarized in Jira.
Blocker visibility	Blockers must clearly mention what is blocked, who owns the next action, and when the next update is expected.
Closure discipline	Tickets must not be closed without final outcome, validation evidence, RCA/decision where applicable, and linked follow-up ticket where required.

5. Specification and Template Standards

This section defines how functional specifications, test cases, approval references, investigation templates, and supporting documents must be prepared, stored, linked, and maintained for Jira tickets.

5.1 Specification Applicability

Ticket Type	Specification / Template Requirement
Story	Functional specification and test cases are mandatory wherever the ticket involves new development, enhancement, setup, movement, extraction, AutoSys, configuration change, output change, or production movement.
Bug	Approved baseline, observation details, expected-vs-actual evidence, test evidence, and fix validation details must be linked.
Support	Investigation/RCA templates must be used where the ticket involves production issue, run failure, data issue, configuration issue, or repeated operational concern.
Question	Clarification template must be used where the question needs formal decision tracking, feasibility confirmation, ownership confirmation, or follow-up ticket creation.

5.2 Document Storage Convention

All functional specifications and test cases must be stored in OneDrive(DHIMPL Teams) under a structured ticket-specific folder. This convention is mandatory for every Story and Bug ticket.

Mandatory Folder Structure:

<CLIENT NAME> / <TICKET ID> / <files>

Rule	Standard
Client folder name	For client projects, use the exact client name, such as AXIS, HDFC, or ICICI. For product, utility, or internal development work, use SURYA.
Ticket folder name	Use the exact Jira ticket ID, such as DHIMPL-1234, DHPROD-567, DHAPP-89, or DM-101.
Folder contents	Store the functional specification, test case file, input/output samples, validation evidence, approval references, and supporting documents for that ticket.
Jira reference	Add the direct OneDrive folder link or document link in the Jira ticket before the ticket is treated as ready for review.
Version control	Revised files must carry a clear version or date so the approved version can be identified.

Folder Examples:

AXIS / DHIMPL-1234 / DHIMPL-1234_Functional_Spec_v1.0.docx
                   / DHIMPL-1234_Test_Cases_v1.0.xlsx
                   / DHIMPL-1234_Sample_Input.csv

SURYA / DHPROD-567 / DHPROD-567_Functional_Spec_v1.0.docx
                    / DHPROD-567_Test_Cases_v1.0.xlsx

5.3 Document/Template Selection Guide

Type	Use When
Development Specification Document	New Development or Logic change in existing binaries.
Extraction Specification Document	New extraction, field addition, layout change, mapping change, downstream file change, or extraction format change.
AutoSys Specification Document	New AutoSys job, schedule change, dependency change, alerting change, or recovery handling.
Run-Control Setup Specification Document	New stream setup or new process setup in an existing stream.
Loader Specification Document	Loader mapping, validation, load rule, rejected record handling, or source-to-target movement.
Production Movement Document	Applicable for clients where one click installation is not present and hand pick movements happen
Configuration Setup Document	New configuration setup, parameter setup, metadata setup, environment-specific setup, or controlled configuration change.
Bug Ticket Intake Template	Defect evidence, expected-vs-actual comparison, observation test case, reproduction details.
Support Ticket Intake Template	Run failure, production issue, configuration issue or operational issue.

5.4 Specification Links

Documents	OneDrive Link
Development Specification Document	Open in OneDrive ↗
Extraction Specification Document	Open in OneDrive ↗
AutoSys Specification Document	Open in OneDrive ↗
Run-Control Setup Specification Document	Open in OneDrive ↗
Loader Specification Document	Open in OneDrive ↗
Production Movement Document	Open in OneDrive ↗
Configuration Setup Document	Open in OneDrive ↗

5.5 Templates for Bug and Story

5.5.1 Bug

Original Story:
Environment:
Binary Version / Release Version:

1. Defect Summary
- What is not working:
- Defect observed in:

2. Expected Behavior
- As per functional spec / approved test case:
- Reference section / test case ID:

3. Actual Behavior
- Observed output / behavior:
- Difference from expected behavior:

4. Reproduction Details
- Input:
- Config:
- Run steps:
- As-on date / run date:
- Reproducible: Yes / No

5. Evidence
- Logs:
- Screenshots:
- Input/output files:
- Comparison sheet:
- DB query / record sample, if applicable:

6. Impact
- Client impact:
- Priority reason:

7. Test Case Observation
- Test case ID:

5.5.2 Support

Client / Product:
Environment:
Stream / Batch / Binary(with version):
As-on Date:
Issue Date / Time If Applicable:

1. Issue Summary
- What failed:
- Where it failed:
- Since when:

2. Evidence
- Error log:
- Diagnostic log:
- Screenshot:
- Input/output sample:
- Config path:
- Scheduler / job details, if applicable:

3. Expected vs Actual
- Expected:
- Actual:
- Difference observed:

4. Impact
- Business impact:
- Production / UAT impact:

5. Action Requested
- Analyze:
- Correct setup:
- Provide RCA: