Version 1.0

Status Active

Owner Head of Engineering

Last Updated 2026-06-06

SOP: Ticket Management

1. Purpose

The purpose of this SOP is to make all engineering work visible, traceable, and properly owned. This SOP defines how tickets are created, classified, updated, assigned, and completed in Taiga.

The goal is to ensure that everyone can clearly understand:

What work exists?
Who owns it?
What status is it in?
What is blocking it?
What needs to happen next?
When is it considered done?

2. Scope

This SOP applies to all engineering work performed by Frontend Backend DevOps QA.

It applies to:

Features
Bugs
Technical tasks
Infrastructure work
Refactoring
QA-related work
Production fixes
Internal engineering improvements

This SOP does not replace detailed product planning, release planning, code review, QA, or deployment procedures. Those are covered by separate SOPs.

3. Core Rule

Mandatory No ticket, no work.

All engineering work must be represented by a ticket in Taiga before work starts.

A ticket must have, at minimum:

Clear title
Description
Type
Status
Owner
Priority
Acceptance criteria or completion criteria

If work is not represented in Taiga, it is not considered officially planned or active engineering work.

4. Rule Strictness

Level	Meaning
Mandatory	Must be followed unless there is an approved exception.
Default	Should normally be followed, but exceptions are allowed.
Recommended	Encouraged, but not strictly required.

5. Definitions

Term	Meaning
Ticket	Any work item tracked in Taiga.
Owner	The person accountable for keeping the ticket updated and moving it forward.
Epic	A large initiative or roadmap item.
User Story	User-facing functionality that belongs to an Epic.
Task	Technical or internal work that belongs to a User Story.
Issue	Bug, defect, incident, or unexpected behavior; independent from Epics/User Stories.
Acceptance Criteria	Conditions that must be met before a User Story or Issue can be considered complete.
Completion Criteria	Conditions that must be met before a Task or Epic can be considered complete.

6. Roles and Responsibilities

Role	Responsibilities
Ticket Creator	Creates the ticket with enough initial information for triage or refinement.
Ticket Owner	Keeps the ticket updated, owns progress, communicates blockers, links related work, and ensures the ticket reaches the correct final status.
Developer	Implements the work, updates ticket status during development, links branches/PRs, and provides testing notes.
Reviewer	Reviews related PRs and provides feedback before merge.
QA	Verifies User Stories and Issues against acceptance criteria and moves them to final status when approved.
DevOps	Supports infrastructure, CI/CD, environments, and deployment-related tickets.
Head of Engineering	Owns the process, resolves unclear ownership, approves exceptions, and ensures the workflow is followed.

Important ownership rule

The ticket owner is accountable for the ticket, but other team members may update the status when they are performing the relevant step.

Examples:

Developer moves ticket to In Review when opening a PR.
QA moves ticket to Done or Closed after verification.
Head of Engineering moves ticket to Postponed when deprioritized.

7. Ticket Types

7.1 Epic

An Epic is a large initiative, roadmap item, or business objective.

Epics are used to group related User Stories.

Examples:

User onboarding redesign
Payment provider integration
Admin dashboard improvements
Infrastructure migration

Rule	Strictness
Epics should represent larger initiatives, not small tasks.	Default
User Stories should belong to an Epic when they are part of planned roadmap work.	Default
Epics are not directly code-reviewed or QA-tested.	Mandatory
Epics are completed when their required child work is complete.	Mandatory

7.2 User Story

A User Story represents user-facing functionality.

User Stories should belong to an Epic.

Recommended format:

As a [type of user],
I want [some capability],
so that [some benefit].

Example:

As an admin,
I want to export user data as CSV,
so that I can analyze users outside the platform.

Rule	Strictness
User Stories should belong to an Epic.	Default
User Stories must have acceptance criteria before development starts.	Mandatory
User Stories must be verified by QA before being marked Done.	Mandatory
User Stories may contain multiple Tasks.	Default

7.3 Task

A Task represents technical or internal work required to complete a User Story.

Tasks belong to User Stories.

Examples:

Add database migration
Create password reset API endpoint
Build password reset frontend form
Configure staging environment variable
Add backend validation
Add unit tests

Rule	Strictness
Tasks should belong to a User Story.	Default
Tasks should describe one clear technical unit of work.	Default
Tasks usually do not require individual QA verification.	Default
Tasks are completed when implementation is merged and completion criteria are met.	Mandatory

Important: QA verifies the parent User Story, not necessarily every internal Task.

Exception: If a Task is independently testable, risky, or not part of a larger User Story, it may require QA verification.

7.4 Issue

An Issue represents a bug, defect, incident, or unexpected behavior.

Issues are independent from Epics and User Stories.

Examples:

Login fails for users with expired sessions
API returns 500 when email is missing
Deployment pipeline fails on staging
Mobile layout is broken on the login page

Rule	Strictness
Issues do not have to belong to an Epic or User Story.	Mandatory
Issues must include reproduction details when possible.	Mandatory
Issues must be verified by QA before being Closed, unless closed as Not a Bug.	Mandatory
Related Epics/User Stories may be referenced manually in the description.	Recommended

Because Taiga may not support directly attaching Issues to User Stories or Epics, related work should be referenced manually.

Recommended format:

## Related Work

Epic: #123 - User onboarding redesign
User Story: #456 - Password reset flow
Related PR: https://...
Related Issue: #789

8. Required Ticket Fields

Every ticket must contain enough information for the team to understand what needs to happen.

8.1 Required for all ticket types

Field	Required	Description
Title	Yes	Clear, action-oriented summary.
Description	Yes	What needs to be done and why.
Type	Yes	Epic, User Story, Task, or Issue.
Status	Yes	Current workflow status.
Owner	Yes	Person accountable for the ticket.
Priority	Yes	Relative importance.
Related Work	When applicable	Epic, User Story, Task, Issue, PR, deployment, or documentation links.

8.2 User Story required fields

User story description
Acceptance criteria
Related Epic
Owner
Priority
Relevant designs, API notes, or business rules

8.3 Task required fields

Technical description
Parent User Story
Completion criteria
Owner
Priority
Relevant technical notes

8.4 Issue required fields

Observed behavior
Expected behavior
Steps to reproduce
Environment
Screenshots, logs, or error messages when available
Priority or severity
Owner

If some information is missing, the Issue should be moved to Needs Info.

9. Ticket Statuses

9.1 Epic statuses

Status	Meaning	Usually moved by
New	Epic idea exists but is not yet refined.	Ticket Creator
Ready	Epic is understood enough to create or organize User Stories.	Head of Engineering / Product / Epic Owner
In Progress	At least one child User Story is actively being worked on.	Epic Owner
Done	Required child work is complete.	Epic Owner / Head of Engineering
Postponed	Epic is valid but intentionally delayed.	Head of Engineering / Product
Archived	Epic is no longer active or relevant.	Head of Engineering / Product

9.2 User Story statuses

Status	Meaning	Usually moved by
New	Story exists but is not yet ready for development.	Ticket Creator
Needs Info	Missing requirements, acceptance criteria, design, API details, or clarification.	Developer / QA / Story Owner
Ready	Story is clear enough to start development.	Product / Head of Engineering / Story Owner
In Progress	Development work has started.	Developer / Story Owner
In Review	PR is open and waiting for review, fixes, or approval.	Developer
Ready for Test	Work is merged and available for QA in the correct environment.	Developer / Story Owner
Done	QA approved and acceptance criteria are met.	QA / Story Owner
Postponed	Story is valid but intentionally delayed.	Product / Head of Engineering

9.3 Task statuses

Status	Meaning	Usually moved by
New	Task exists but is not yet refined or started.	Ticket Creator
Needs Info	Task is missing technical clarification.	Developer / Task Owner
Ready	Task is clear enough to start.	Task Owner / Developer
In Progress	Work has started.	Developer
In Review	PR is open and waiting for review.	Developer
Done	Implementation is complete, merged, and linked to the parent User Story if applicable.	Developer / Reviewer / Task Owner
Postponed	Task is valid but intentionally delayed.	Task Owner / Head of Engineering

9.4 Issue statuses

Status	Meaning	Usually moved by
New	Issue was reported and needs triage.	Ticket Creator
Needs Info	Missing reproduction steps, logs, screenshots, expected behavior, or environment details.	Developer / QA / Issue Owner
In Progress	Someone is investigating or fixing the Issue.	Developer
In Review	Fix is in PR review.	Developer
Ready for Test	Fix is merged and available for QA verification.	Developer / Issue Owner
Closed	QA verified the fix, or the Issue is otherwise resolved.	QA / Issue Owner
Not a Bug	Expected behavior, invalid report, duplicate, or not reproducible after review.	QA / Developer / Head of Engineering
Postponed	Issue is valid but intentionally delayed.	Head of Engineering / Product

10. Ticket Workflows

10.1 Epic workflow

New → Ready → In Progress → Done

Exception paths:

New / Ready / In Progress → Postponed
New / Ready / Postponed → Archived

10.2 User Story workflow

New → Ready → In Progress → In Review → Ready for Test → Done

Exception paths:

New / Ready → Needs Info
Needs Info → Ready
In Review → In Progress
Ready for Test → In Progress
New / Ready / In Progress → Postponed

10.3 Task workflow

New → Ready → In Progress → In Review → Done

Exception paths:

New / Ready → Needs Info
Needs Info → Ready
In Review → In Progress
New / Ready / In Progress → Postponed

10.4 Issue workflow

New → In Progress → In Review → Ready for Test → Closed

Exception paths:

New → Needs Info
Needs Info → In Progress
New / Needs Info → Not a Bug
Ready for Test → In Progress
New / In Progress → Postponed

11. Procedure

11.1 Creating a ticket

Anyone may create a ticket.

When creating a ticket:

Select the correct ticket type.
Add a clear title.
Add a useful description.
Add priority.
Add owner, if known.
Add acceptance criteria or completion criteria.
Link related work where applicable.
Set the correct initial status.

Ticket Type	Initial Status
Epic	New
User Story	New
Task	New
Issue	New

11.2 Refining a ticket

Before a ticket can move to Ready, it must be clear enough for work to start.

A ticket is ready when:

The work is understandable.
The owner is clear.
The expected result is clear.
Acceptance criteria or completion criteria exist.
Dependencies are known.
Required designs, API notes, logs, or business rules are available.

If this information is missing, move the ticket to Needs Info.

11.3 Starting work

Before work starts:

Confirm the ticket exists.
Confirm the ticket is assigned to an owner.
Confirm the ticket is clear enough to start.
Move the ticket to In Progress.
Create a branch or begin the work according to the Git Flow SOP.

Mandatory Work must not start without a ticket.

11.4 Moving to review

When implementation is ready for review:

Open a PR.
Link the PR to the ticket.
Ensure the PR description explains what changed.
Ensure pipelines are passing or failures are clearly explained.
Move the ticket to In Review.

The detailed PR process is covered by the Pull Request SOP.

11.5 Moving to Ready for Test

A User Story or Issue may move to Ready for Test only when:

Implementation is merged.
The change is available in the correct test environment.
Acceptance criteria are documented.
Developer testing notes are provided.
Known limitations are documented.
Related PRs are linked.

Tasks do not normally move to Ready for Test.

11.6 Completing a User Story

A User Story may move to Done only when:

Acceptance criteria are met.
QA has verified the behavior.
Required PRs are merged.
No blocking defects remain.
Related Tasks are complete or no longer required.
Ticket is updated with relevant notes.

11.7 Completing a Task

A Task may move to Done when:

Implementation is complete.
Related PR is merged.
Completion criteria are met.
Parent User Story is linked, when applicable.
No required review comments remain unresolved.

QA is not required for every Task unless explicitly requested.

11.8 Closing an Issue

An Issue may move to Closed when:

The fix is implemented.
The fix is available in the correct test environment.
QA has verified the fix.
Related PRs are linked.
Reproduction steps no longer produce the issue.

An Issue may move to Not a Bug when:

The behavior is expected.
The report is invalid.
The issue is a duplicate.
The issue cannot be reproduced after reasonable investigation.
The reported behavior is outside the agreed scope.

12. Exceptions

12.1 Urgent production incidents

For urgent production incidents, work may begin before the ticket is fully prepared.

However:

A ticket must be created as soon as possible.
The ticket must describe the incident or fix.
The related PR must be linked.
The deployment must be traceable.
The ticket must be updated after resolution.

This is the only exception to No ticket, no work.

12.2 Small fixes

Small fixes still require a ticket.

Examples:

Typo fixes
Small UI fixes
Configuration changes
Minor bug fixes
Small CI/CD changes

If the work is worth changing code, configuration, infrastructure, or production behavior, it is worth tracking.

12.3 Unclear work

If a ticket is unclear, it should not move forward.

Move it to Needs Info and add a comment explaining what is missing.

Examples:

Missing acceptance criteria
Unclear expected behavior
No reproduction steps
Missing design
Missing API contract
Unclear owner
Unclear priority

12.4 Postponed work

Use Postponed when the work is valid but intentionally delayed.

Do not use Postponed to hide unclear, abandoned, or forgotten work.

A postponed ticket should include a comment explaining why it was postponed.

13. Definition of Done

13.1 Epic Definition of Done

An Epic is Done when:

Required child User Stories are Done.
Required Tasks are Done.
Open Issues related to the Epic are either Closed, Postponed, or accepted as known issues.
Epic owner confirms the Epic scope is complete.

13.2 User Story Definition of Done

A User Story is Done when:

Acceptance criteria are met.
Required Tasks are complete.
Required PRs are merged.
QA has approved the story.
No blocking bugs remain.
Relevant documentation is updated, when applicable.
Deployment status is clear.
Ticket is updated and moved to Done.

13.3 Task Definition of Done

A Task is Done when:

Completion criteria are met.
Related PR is merged, if code was changed.
Review comments are resolved.
Parent User Story is linked, when applicable.
Ticket is updated and moved to Done.

13.4 Issue Definition of Closed

An Issue is Closed when:

The issue has been fixed or otherwise resolved.
QA has verified the fix, when a code change was made.
Related PR is merged, if applicable.
The ticket includes enough notes to understand the resolution.
Ticket is moved to Closed.

14. Short Checklist

14.1 Before starting work

Ticket exists.
Ticket has correct type.
Ticket has clear title.
Ticket has useful description.
Ticket has owner.
Ticket has priority.
Acceptance criteria or completion criteria are present.
Related Epic/User Story/Task/Issue is linked when applicable.
Ticket is Ready or has enough information to start.

14.2 During work

Ticket status is updated.
Blockers are added as comments.
Related branch/PR is linked.
Scope changes are documented.
Ticket owner remains clear.

14.3 Before review

PR is opened.
PR is linked to the ticket.
PR description explains the change.
Pipelines pass or failures are explained.
Ticket is moved to In Review.

14.4 Before QA

Work is merged.
Work is available in the correct test environment.
Testing notes are provided.
Acceptance criteria are clear.
Known limitations are documented.
Ticket is moved to Ready for Test.

14.5 Before final status

Acceptance criteria or completion criteria are met.
QA approval exists, when required.
Related PRs are merged.
Blockers are resolved or documented.
Ticket comments explain important decisions.
Ticket is moved to Done, Closed, Not a Bug, Archived, or Postponed.

15. Ticket Templates

15.1 User Story template

## User Story

As a [type of user],
I want [capability],
so that [benefit].

## Description

Describe the required behavior and context.

## Acceptance Criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Related Work

Epic:
Related Tasks:
Related Issues:
Related PRs:

## Notes

Add designs, API notes, business rules, risks, or dependencies.

15.2 Task template

## Description

Describe the technical work required.

## Completion Criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Related Work

Parent User Story:
Related PRs:

## Technical Notes

Add implementation details, dependencies, risks, or important decisions.

15.3 Issue template

## Observed Behavior

What happened?

## Expected Behavior

What should happen?

## Steps to Reproduce

1.
2.
3.

## Environment

Environment:
Browser/device:
User/account:
Version/build:

## Evidence

Screenshots:
Logs:
Error messages:

## Related Work

Related User Story:
Related Epic:
Related PRs:

## Acceptance Criteria

- [ ] Issue no longer reproduces
- [ ] Fix is verified in the correct environment
- [ ] No related regression is observed

16. Workflow Diagram

16.1 Full ticket lifecycle

flowchart TD
  A[Work Identified] --> B[Create Ticket in Taiga]
  B --> C{Correct Ticket Type?}

  C -- Epic --> E1[Create Epic]
  C -- User Story --> S1[Create User Story]
  C -- Task --> T1[Create Task]
  C -- Issue --> I1[Create Issue]

  E1 --> E2[New]
  E2 --> E3[Ready]
  E3 --> E4[In Progress]
  E4 --> E5[Done]

  S1 --> S2[New]
  S2 --> S3{Enough Info?}
  S3 -- No --> S4[Needs Info]
  S4 --> S3
  S3 -- Yes --> S5[Ready]
  S5 --> S6[In Progress]
  S6 --> S7[In Review]
  S7 --> S8[Ready for Test]
  S8 --> S9{QA Approved?}
  S9 -- No --> S6
  S9 -- Yes --> S10[Done]

  T1 --> T2[New]
  T2 --> T3{Enough Info?}
  T3 -- No --> T4[Needs Info]
  T4 --> T3
  T3 -- Yes --> T5[Ready]
  T5 --> T6[In Progress]
  T6 --> T7[In Review]
  T7 --> T8[Done]

  I1 --> I2[New]
  I2 --> I3{Valid Bug?}
  I3 -- Needs Info --> I4[Needs Info]
  I4 --> I3
  I3 -- No --> I5[Not a Bug]
  I3 -- Yes --> I6[In Progress]
  I6 --> I7[In Review]
  I7 --> I8[Ready for Test]
  I8 --> I9{QA Approved?}
  I9 -- No --> I6
  I9 -- Yes --> I10[Closed]

16.2 Simplified team responsibility flow

flowchart LR
  A[Any Team Member: Create Ticket] --> B[Owner: Refine Ticket]
  B --> C{Ready?}
  C -- No --> D[Owner / Requester: Add Missing Info]
  D --> B
  C -- Yes --> E[Developer: Implement Work]
  E --> F[Developer: Open PR]
  F --> G[Reviewer: Review PR]
  G --> H{Approved?}
  H -- No --> E
  H -- Yes --> I[Developer: Merge / Prepare for QA]
  I --> J[QA: Verify Work]
  J --> K{Passed?}
  K -- No --> E
  K -- Yes --> L[Owner / QA: Move to Final Status]

17. Version History

Version	Date	Author	Changes
0.1	2026-06-06	Head of Engineering	Initial draft.
1.0	2026-06-06	Head of Engineering	Active.