Software Project Management with Agile Scrum

Overview

For the IS212 Software Project Management module, our team (G2T1) adopted a structured Agile Scrum methodology to deliver a high-quality software product. As the Scrum Master and Developer, I facilitated the process to ensure efficient delivery, high code quality, and adaptability to changing requirements.

Agile Workflow

We operated on a standard Scrum cycle with 2-week sprints over a total of 3 sprints. Our workflow was designed to maximize collaboration and transparency.

Key Meetings & Cadence

• Sprint Planning: Defined sprint goals, refined the backlog, and estimated stories using Planning Poker. We utilized a Modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) to encourage discussion on complexity and uncertainty.
• Daily Stand-up: Updates every 2-3 days via Zoom or Telegram/Google Form to log blockers and progress. We maintained a Daily Standup Tracker (Google Forms -> Excel) to monitor issues and facilitate 1-on-1 discussions.
• Sprint Review: Demonstrated completed features to stakeholders.
• Sprint Retrospective: Reflected on workflow and team efficiency using the "4Ls" framework (Liked, Learned, Lacked, Longed For).
• Backlog Grooming: Ad-hoc sessions to refine stories and clarify requirements.

Team Coordination

• Chunking Strategy: Stories were grouped by "chunks" (overarching features).
• Pair Programming: Each chunk was assigned to a pair (Frontend + Backend) to ensure full-stack integration and continuous peer review.
• Jira Workflow: We tracked progress using a clear board flow: To Do → In Progress → In Review → Done.
• Velocity Management: After an initial setup-heavy Sprint 1 (15 points), we recalibrated to a sustainable velocity of 20 points for Sprint 2, ensuring steady progress without burnout.

User Stories & Acceptance Criteria (ACs)

We maintained a rigorous approach to requirements management to ensure traceability and quality.

• Format: Stories followed the standard template: "As a [role], I want to [feature], in order to [benefit]."
• Acceptance Criteria (ACs): We employed both Given-When-Then scenarios and checklist-based criteria to strictly define scope and prevent creep.
• Estimation: We used Planning Poker to estimate story points, establishing consistent criteria:
  • 1 Point: Simple CRUD, minimal logic.
  • 2 Points: Multi-collection CRUD, complex validation.
  • 3-5 Points: External integrations, complex logic.
• Definition of Done (DoD): Strictly tied to Acceptance Criteria (ACs), basic Non-Functional Requirements (NFRs), and passing Unit Tests.
• Traceability: Every feature implementation was directly traceable to a User Story and its ACs on Jira. Subtasks were used extensively for developer-level tracking.

Commit Style

To maintain a clean and understandable history, we introduced a standardized commit naming convention following feedback from our second retrospective.

Format: <type>: [<Jira-Ticket>/Feature] <Summary>

Valid Types:

• feat: Adding a new feature
• fix: Squashing a bug
• chore: Updating dependencies/build scripts
• docs: Writing documentation
• style: Formatting changes
• refactor: Reworking code without logic change
• test: Adding or improving tests

This ensured transparent tracking, easier identification of changes, and better collaboration.

CI Features

We implemented a robust Continuous Integration (CI) pipeline with a "Local-first" strategy, using GitHub Actions as the gatekeeper. This evolved from an initially heavy, production-oriented pipeline to a more optimized, developer-friendly workflow.

CI Strategy

1. Local Layer (Pre-push Hooks):

   • Executed automatically via Git hooks (~3-4 mins).
   • Frontend: TypeScript + Vite build validation.
   • Backend: Unit tests run only on changed services (70% coverage enforced).
   • Security: Optional Gitleaks scan.
   • Benefit: Catches integration errors locally, ensuring only stable builds reach the remote repo.

2. Cloud Layer (GitHub Actions):

   • Triggered on Pull Requests to the main branch (~3-5 mins).
   • Backend Tests: Runs 11 services in parallel; fails below 70% coverage.
   • Lint & Security: Frontend build (blocking), ESLint + TypeScript (warnings), and Gitleaks (blocking).
   • Benefit: Acts as the official merge gatekeeper, ensuring high reliability and stable merges.

Automated Testing

• Unit Tests: Implemented for 14/17 services with ≥70% coverage.
• End-to-End (E2E) Tests: 8 Playwright test suites covering major user flows, verifying integration between Frontend, Backend, MongoDB, and Supabase.
• Evolution: We shifted from manual test documentation in Sprint 1 to full automation by Sprint 3, significantly reducing regression risks.

System Design & Tech Stack

• Architecture: Microservices-based (Python Flask) with Docker containerization.
• Frontend: React with TailwindCSS and Shadcn components.
• Database: MongoDB Atlas (chosen for flexibility and cloud accessibility).
• Authentication: Supabase (chosen for team familiarity).
• Communication: WebSockets for real-time changes on the task-board and Server-Sent Events (SSE) for real-time notifications.