Skip to main content

Project Methodology

This document describes the lightweight delivery process used by the Athlora team. It combines a Gitea Projects Kanban board for everyday work tracking with Sprint checkpoints for planning, stakeholder feedback, and improvement.

1. Methodology Overview​

Athlora uses a lightweight Kanban-and-Sprint process. Gitea Projects is the live Kanban board and source of day-to-day work status. Sprint windows provide a shared delivery focus and a point to review completed work, client feedback, and process improvements.

This approach fits the team because:

  • Visible flow. The board shows all work from backlog to completion and prevents work from being lost in chat.
  • Focused delivery. The team identifies a Sprint goal and the most valuable ready issues, while retaining flexibility when university commitments or technical dependencies change.
  • Practical coordination. Short planning, progress, review, and improvement records create useful evidence without unnecessary ceremony.
  • Continuous quality. Authors complete a documented self-review, run applicable automated checks, update documentation, and confirm deployment readiness before work reaches Done.

2. Core Principles​

2.1 Shared Responsibilities​

The team works cross-functionally rather than assigning permanent frontend or backend silos. For each Sprint, the team identifies who will coordinate product/client decisions and who will facilitate the workflow, blockers, and meeting record. Any team member can pick up a task based on:

  • Availability — who has time this week.
  • Interest — who wants to learn or strengthen a skill.
  • Context — who is closest to the problem or has the most recent understanding of the area.

This approach keeps the bus factor low. If one member is unavailable, the rest of the team can cover their work without handoff friction because there is no ownership silo.

2.2 Flexible Workflow​

Tasks flow through the board at their own pace. There is no rule that a card must move from "In Progress" to "Done" within a fixed window. A task stays where it is until the work is genuinely complete and passes quality gates.

This means:

  • A simple documentation fix might move from "To Do" to "Done" in an hour.
  • A complex feature like offline-first logging might sit in "In Progress" for days while the developer iterates, tests, and refines.
  • Both are normal and expected.

2.3 Sprint Checkpoints​

Sprint milestones are delivery checkpoints, not a restriction on useful work. At the start of a Sprint, the team records a goal, the ready issues it expects to deliver, and any important dependencies. During the Sprint, work continues to flow through the Kanban board. At the end, the team records what was delivered, client feedback, carry-over work, and one or more practical improvements for the next Sprint.

3. The Visual Board​

The team uses the Gitea Projects workspace as the primary live view of work status. It contains the Sprint 1-4 project views and bug tracker. It is not the only record: Gitea issues carry scope and acceptance criteria, delivery rows sequence the Sprint's work, and the delivery roadmap keeps longer-range status. The board is the common surface those records move across. Every piece of work — features, bugs, documentation, infrastructure — is represented as a card on the board.

3.1 Board Columns​

ColumnMeaning
BacklogValid work that has been identified but is not yet scheduled. Cards here are prioritised but not yet committed to.
To DoWork that has been selected for the current cycle. The team has reviewed it, confirmed it is well-defined, and intends to start it soon.
In ProgressSomeone is actively working on this. There should be a branch and issue link where practical.
VerificationThe author checks the final diff, runs the applicable local and CI checks, and confirms acceptance criteria before merging.
DoneThe work is merged, applicable checks pass, documentation is updated, and the card is complete.

3.2 How Cards Move​

Backlog → To Do → In Progress → Verification → Done
  • Cards normally move left to right. A card may return to In Progress when self-review or automated checks reveal that it is not ready.
  • A card in In Progress should have a linked branch or issue where practical. If someone is blocked, the card stays in In Progress and the blockage is flagged to the team.

4. Work Items​

4.1 Issues​

Every unit of work is tracked as a Gitea issue. Issues provide a natural place to record:

  • What needs to be done (description).
  • Why it needs to be done (link to the dev plan, API contract, or build spec).
  • Acceptance criteria (what "done" looks like).
  • Who is working on it (assignee).
  • Where the code lives (linked PR).

4.2 Labels​

Issues are categorised with labels so the team can filter and prioritise:

LabelScope
frontendReact/Vite UI work
backendExpress API, PostgreSQL, migrations
docsDocusaurus documentation
e2ePlaywright end-to-end tests
bugSomething is broken
enhancementImprovement to existing functionality
choreMaintenance, dependency updates, CI changes

5. Workflow in Practice​

A typical work cycle looks like this:

  1. Plan the Sprint. The team records a short Sprint goal and selects ready issues from Backlog into To Do.
  2. Pull from To Do. A team member takes a selected card when they have capacity.
  3. Create a branch. Following the git methodology, they branch off main with a descriptive name (e.g., feature/live-logging-undo).
  4. Work on the branch. If using an agent-assisted session, the agent writes code and commits; the developer creates the branch, pushes, and performs the final self-review. If working directly, the developer commits following Conventional Commits.
  5. Open a PR when ready to merge. The pull request is the merge record for the work and links the branch to its issue when one exists.
  6. Move to Verification. The author reviews the complete diff against the issue and acceptance criteria, runs the applicable checks, and checks the deployment and documentation impact.
  7. Fix findings. If self-review or a check finds a defect, the developer (or agent) fixes it on the same branch and repeats verification.
  8. Merge. Once the author has completed self-review and required checks pass, the PR is merged into main. Where source code changes, review the Gitea coverage report and its lowest-covered-file list as part of the quality discussion. The card then moves to Done.
  9. Review and improve. At the Sprint checkpoint, the team reviews delivered work and feedback, then records any follow-up work or process improvement.

6. Sprint Records​

Each Sprint record contains the evidence appropriate to the work completed:

  • Sprint dates and goal.
  • Selected issues, assignments, dependencies, and status.
  • Relevant pull requests and merged implementation.
  • Client feedback and resulting backlog changes.
  • User-story and UAT progress where verification evidence exists.
  • A short improvement action for the next Sprint.

All three Sprint folders (sprint-1, sprint-2, sprint-3) share the same structure: both concise meeting records and the retained raw chat transcript, alongside client-meeting notes and user stories. The transcript is the source evidence; the concise records are an accurate summary of its material decisions and outcomes.

AI declaration​

This document was created or updated with the assistance of OpenCode[openai/gpt-5.6-terra].