Skip to main content

​
Overview

The Saint Giong Job Manager (SGJM) team follows an Agile development methodology combining Scrum and Kanban practices. This hybrid approach enables iterative development, continuous delivery, and flexible task management throughout the project lifecycle.

​
Task Management with Tuturuuu

Kanban Board

Access the team’s Kanban board for real-time task tracking and sprint management.

​
Board Structure

Our Kanban board is organized into 5 groups with multiple columns:
ColumnPurpose
DocumentsGeneral project documentation and artifacts
Meetings DocumentationMeeting notes and action items
Daily Stand-upsDaily standup logs and updates
ColumnPurpose
Product BacklogPrioritized list of features and tasks
Un-CategorizedNew tasks awaiting categorization
ColumnPurpose
Next SprintTasks planned for the upcoming sprint
Current SprintTasks committed to the current sprint
In ProgressTasks actively being worked on
StagingCompleted tasks deployed to staging environment
In ReviewTasks awaiting code review or approval
ColumnPurpose
DoneSuccessfully completed and verified tasks
CancelledTasks that were cancelled or deprioritized
DuplicatedTasks identified as duplicates
ColumnPurpose
ClosedArchived tasks from previous sprints

​
Task Categories

Tasks are categorized by type using labels:

Feature

New functionality implementation

Bug Fix

Defect resolution and corrections

Documentation

Technical docs and reports

Design

UI/UX and architecture design

Research

Technical investigation and POCs

DevOps

Infrastructure and deployment

​
Sprint Cadence

​
Sprint Duration

Each sprint runs for 2 weeks, aligning with bi-weekly reviews with the course lecturer.

​
Sprint Ceremonies

CeremonyFrequencyDurationPurpose
Sprint PlanningStart of sprint1-2 hoursDefine sprint goals and select backlog items
Daily StandupDaily15 minutesProgress updates and blocker identification
Sprint ReviewEnd of sprint1 hourDemo completed work to stakeholders
RetrospectiveEnd of sprint30-45 minutesProcess improvement discussion

​
Development Workflow

​
Git Branch Strategy

The team follows a feature branch workflow: 
main
  └── develop
        ├── feature/auth-sso
        ├── feature/job-post-crud
        ├── bugfix/login-validation
        └── docs/api-reference

​
Commit Conventions

All commits follow the conventional commit format:
<type>(<scope>): <description>

[optional body]

[optional footer]
Types:
  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style/formatting
  • refactor: Code refactoring
  • test: Adding/updating tests
  • chore: Maintenance tasks
Team members are expected to:
  • Commit at least once per working day when actively developing
  • Push changes before end of day to enable collaboration
  • Keep commits atomic and focused on single changes
  • Reference task IDs in commit messages when applicable

​
Code Review Process

1

Create Pull Request

Developer creates PR from feature branch to develop
2

Assign Reviewers

At least one team member must review the code
3

Address Feedback

Resolve comments and make requested changes
4

Approval & Merge

Once approved, merge using squash merge strategy

​
Team Agreements

​
Working Hours

  • Core collaboration hours: 9:00 AM - 5:00 PM (GMT+7)
  • Flexibility allowed for individual schedules
  • Response expected within 4 hours during working hours

​
Communication Channels

ChannelPurpose
DiscordReal-time team communication and quick discussions
GitHub IssuesTechnical discussions and bug tracking
TuturuuuTask management and sprint tracking
EmailFormal communications with supervisor

​
Meeting Policy

Attendance at all scheduled meetings is mandatory.
Absence Protocol:
  • Provide 24-hour advance notice for planned absences
  • Submit valid justification with supporting evidence
  • Unexcused absences may result in contribution penalties

​
Definition of Done

A task is considered Done when:

​
Sprint Metrics

​
Velocity Tracking

The team tracks velocity to improve estimation accuracy:
  • Story Points: Fibonacci sequence (1, 2, 3, 5, 8, 13)
  • Velocity: Average story points completed per sprint
  • Burndown: Daily progress visualization

​
Quality Metrics

MetricTarget
Code coverage> 70%
PR review time< 24 hours
Bug escape rate< 5%
Sprint completion> 85%

​
Continuous Improvement

​
Retrospective Format

The team uses the Start-Stop-Continue format:

Start

New practices to adopt

Stop

Ineffective practices to eliminate

Continue

Effective practices to maintain

​
Action Items

  • Retrospective action items are tracked in Tuturuuu
  • Each item has an assigned owner and due date
  • Progress is reviewed at the next retrospective

​
Integration with Squad

​
Cross-Team Coordination

The SGJM team coordinates with the SGJA (Job Applicant) team through:
  • Weekly sync meetings for API integration discussions
  • Shared Kafka topic definitions for event-driven communication
  • Joint sprint reviews for integrated feature demos

​
Shared Resources

  • Common design system (bamboo-ui)
  • Unified API documentation
  • Shared database sharding strategy