BREAKING:

Scrum Board & Issue Management – Standard Operating Procedure (SOP)

1. Purpose

This SOP defines standardized practices for managing Product Backlog Items (PBIs), using the Scrum Board, and creating issues in Jira to ensure consistency, clarity, and scalability across Product, Development, QA, and UX teams.


2. Scope

This SOP applies to:

  • Product Owner (PO)
  • Developers (Frontend, Backend, Mobile)
  • QA Engineers
  • Designers (UX/UI)

3. Definitions

  • PBI (Product Backlog Item): Any unit of work in the backlog (Story, Task, Bug, Improvement, Spike)
  • Sprint: A time-boxed iteration where selected PBIs are executed
  • Backlog: A prioritized list of PBIs not yet committed to a sprint

4. PBI Creation Guidelines (CRITICAL)

4.1 General Rules for All PBIs

Every PBI must include:

  • Title (clear and structured)
  • Context / Goal
  • Scope
  • Acceptance Criteria
  • Labels
  • Assignee (if known)

4.2 Issue Type Usage (When to Use What)

Issue TypeWhen to Use
EpicLarge feature grouping multiple PBIs
StoryUser-facing functionality
TaskTechnical implementation
BugDefect or unexpected behavior
ImprovementUX/UI or performance enhancement
SpikeResearch or investigation

4.3 Story (PBI) Creation – For Product Owner

Used for: User-facing features

Template:

Title: [Feature] User can login

Description:
As a user,
I want to log in,
So that I can access my account

Context:
Explain why this feature is needed

Scope:
- Login screen
- Validation logic
- Error handling

Acceptance Criteria:
- User can enter email/password
- Successful login redirects to dashboard
- Error message shown if credentials are invalid

Labels: frontend, backend

👉 Rules:

  • Must describe user value
  • Must include clear acceptance criteria
  • PO is responsible for creating Stories

4.4 Task Creation – For Developers

Used for: Technical work (non user-facing)

Template:

Title: [API] Create login endpoint

Description:
Context:
Implement backend API for login

Scope:
- Create POST /login
- Validate input
- Return JWT

Technical Notes:
- Use existing auth service

Acceptance Criteria:
- API returns 200 on success
- API returns 401 on failure

Labels: backend, api

👉 Rules:

  • Derived from Story or created for internal work
  • Must be actionable and specific

4.5 Bug Creation – For QA / Team

Template:

Title: [Bug] App crash during login

Context:
App crashes when user enters incorrect password

Steps to Reproduce:
1. Open app
2. Enter wrong password
3. Submit

Expected Result:
App should show error message

Actual Result:
App crashes

Environment:
iOS / Android / Web

Labels: mobile

👉 Rules:

  • Must include reproducible steps
  • Must clearly define Expected vs Actual

4.6 Improvement Creation – For UX / PO / Team

Template:

Title: [UX] Low button visibility on Home screen

Context:
Users struggle to notice the primary button

Problem:
Button color lacks contrast

Suggestion:
- Increase contrast
- Use primary color

Impact:
Improve usability and conversion

Acceptance Criteria:
- Button meets accessibility contrast standards
- Clearly visible on all devices

Labels: ux, ui

👉 Rules:

  • Focus on improving existing experience
  • Must describe problem + impact

4.7 Spike Creation – For Research

Template:

Title: [Spike] Research performance tracking

Goal:
Identify methods to measure screen load time

Scope:
- Evaluate tools
- Compare approaches

Output:
- Recommendation
- Implementation plan

👉 Rules:

  • Must produce a clear outcome
  • Time-boxed

5. Scrum Board Usage

5.1 Backlog vs Sprint Rule

  • Issues in Backlog must NOT be updated
  • Only issues in an Active Sprint can change status

5.2 Sprint Flow

Backlog → Sprint Planning → Active Sprint → Review → Close


5.3 Workflow Status

  • Backlog
  • Selected
  • In Progress
  • Resolve
  • In Review
  • Done

5.4 Daily Operations

  • Move issue to In Progress when starting
  • Move to Resolve when development is done
  • Move to In Review for QA/Review
  • Move to Done after validation

5.5 WIP Limit

  • Max 1–2 issues in progress per person

6. Definition of Done (DoD)

An issue is Done when:

  • Code completed
  • Code reviewed
  • QA passed
  • No critical bugs
  • Deployed (if required)

7. Backlog Grooming

Performed regularly by PO + team:

  • Clarify requirements
  • Add acceptance criteria
  • Assign labels
  • Estimate

8. Sprint Commitment

  • Team commits during Sprint Planning
  • No new issues added after Sprint starts
  • Exception: Critical bugs only

9. GitHub Integration (Optional but Recommended)

  • Use Jira Issue ID in branch name
    • Example: FE-123-login-api
  • Link PR to Jira issue
  • Ensure traceability between code and task

10. Roles & Responsibilities

Product Owner (PO)

  • Create and prioritize Stories
  • Define acceptance criteria
  • Ensure backlog readiness

Developers

  • Create Tasks
  • Update status daily
  • Follow workflow

QA

  • Create Bugs
  • Validate issues
  • Ensure quality before Done

UX/Design

  • Create Improvements
  • Provide UX recommendations

11. Expected Outcomes

  • Clear and structured backlog
  • Consistent issue creation
  • Transparent sprint execution
  • Improved collaboration across teams

One Comment

  • […] Scrum Board & Issue Management – Standard Operating Procedure (SOP) JIRA SETUP & IMPLEMENTATION PLAN Firebase Runtime Sync (Shadow Migrate) Tạo môi […]

Post A Comment

Your email address will not be published. Required fields are marked *

Leave a Reply