Skip to content
Sports Live Documentation

Project Management Methodology

Chosen Methodology: Agile (Scrum Framework)

Section titled “Chosen Methodology: Agile (Scrum Framework)”

We use the Agile methodology, following the Scrum framework, to ensure flexibility, collaboration, and continuous delivery of working software.

Why Agile for Sport Live Feeds?

Section titled “Why Agile for Sport Live Feeds?”
  • Requirements may evolve after stakeholder feedback.
  • Frequent delivery allows us to adapt quickly.
  • Encourages transparency, communication, and accountability.
  • Short iterations keep progress measurable and visible.

We work in two-week sprints, providing enough time for meaningful progress while maintaining rapid feedback loops

Section titled “We work in two-week sprints, providing enough time for meaningful progress while maintaining rapid feedback loops”

Scrum Process

Section titled “Scrum Process”

Roles

Section titled “Roles”
  • Product Owner – Represents stakeholder interests and prioritizes backlog.
  • Scrum Master – Facilitates ceremonies, removes blockers.
  • Development Team – Builds, tests, and delivers product increments.

Ceremonies

Section titled “Ceremonies”
  1. Sprint Planning – Define sprint goals, select backlog items, estimate work.
  2. Daily Standups – Quick syncs to report progress and highlight blockers.
  3. Sprint Review – Demo completed features to stakeholders and gather feedback.
  4. Sprint Retrospective – Identify improvements for the next sprint.

Workflow Diagram

Section titled “Workflow Diagram”

Backlog → Sprint Planning → Development → Daily Standups → Sprint Review → Retrospective → Next Sprint

Tools Used

Section titled “Tools Used”
  • React – Frontend framework for building fast, responsive UI.
  • Notion – Central hub for sprint boards, backlog, and documentation.
  • Discord – Async communication, quick updates, and stakeholder coordination.
  • Git & GitHub – Version control and CI/CD deployment.
  • VS Code – Main IDE for coding and configuration.

Workflow Structure

Section titled “Workflow Structure”

Sprint Length

Section titled “Sprint Length”
  • Each sprint runs for 2 weeks.

Planning and Meetings

Section titled “Planning and Meetings”
MeetingFrequencyFormatPurpose
Sprint PlanningEvery second TuesdayIn-personPlan the sprint, estimate tasks
Sprint Check-ins3x per weekDiscordReview progress, unblock teammates
Sprint ReviewEvery DayIn-person/Discord/WhatsappDemo features, collect feedback

Definition of Done (DoD)

Section titled “Definition of Done (DoD)”
  • Code reviewed and merged.
  • Feature tested and passes QA.
  • Documentation updated.
  • Stakeholder acceptance obtained.

Continuous Improvement

Section titled “Continuous Improvement”
  • Retrospective action items applied in next sprint.
  • Regular evaluation of workflow and tools.
  • Experimentation with new practices for efficiency.

Proof of Agile in Action

Section titled “Proof of Agile in Action”

We maintain our project board in Notion:
📌 View on Notion

Includes:

  • Sprint backlog with priorities.
  • Columns: Backlog → To Do → In Progress → Review → Done.
  • Assigned tasks with due dates.
  • Links to GitHub branches and PRs.
  • Sprint deliverable tags.

Additional evidence:

  • Meeting notes from Sprint Planning.
  • Standup summaries in Discord.
  • Screenshots from Sprint Reviews.
  • Retrospective improvement notes.

Definition of Done (DoD)

Section titled “Definition of Done (DoD)”
  • Code reviewed and merged.
  • Feature tested and passes QA.
  • Documentation updated.
  • Stakeholder acceptance obtained.

Continuous Improvement

Section titled “Continuous Improvement”
  • Retrospective action items applied in next sprint.
  • Regular evaluation of workflow and tools.
  • Experimentation with new practices for efficiency.

Workflow Structure

Section titled “Workflow Structure”

Architecture Overview

Section titled “Architecture Overview”

Frontend – React

  • Renders UI components for login, dashboard, preferences, match setup, and live input.
  • Fetches data from backend APIs and WebSockets for live updates.

Backend API – Node.js + Express

  • RESTful endpoints for matches, events, and preferences.
  • WebSocket support for real-time updates.

Database – PostgreSQL or MongoDB

  • Stores match info, events, player/team data, and user preferences.

Deployment – GitHub Pages / Hosting via CI/CD

  • Automatic build and deploy from the main branch.

Deployment Process

Section titled “Deployment Process”

  1. Branching Strategy

    • Features: feature/<name>
    • Fixes: fix/<name>
    • Merge via pull requests to main.

  2. Build & Test

    • astro build runs locally and in CI.
    • Manual QA for dashboard, event feed, and live updates.

  3. Deployment

    • Push to main triggers GitHub Actions.
    • Astro build output deployed to GitHub Pages or hosting service.

  4. Post-Deployment

    • Verify live environment against sprint goals.
    • Perform smoke tests.

References

Section titled “References”