Skip to content

Team Processes

Jump to bottom
David Zhu edited this page Apr 6, 2025 · 4 revisions

Agile Overview

Sprint Cadence

  • Sprint Length: 1 week
  • Ceremonies:
    • Sprint Planning / Sprint Review (start of each sprint)
    • Standups (once a week, 15 mins)
    • Retrospective (every second sprint or as needed)

Tools We Use

  • Backlog & Task Board: GitHub Project
  • Estimation: Story points (fibonacci scale)
  • Demo: Live in standups or async via screenshots/recordings

Workflow

  1. Prioritize the backlog during planning
  2. Break down features into small, manageable tasks
  3. Assign story points
  4. Collaborate actively (pair up, unblock others)
  5. Open draft PRs early and push often
  6. Submit clean, tested PRs with linked issues
  7. Demo completed features at end of sprint
  8. Reflect in retrospectives

Work In Progress (WIP) Limit: Developers should have no more than 1–2 active tasks at a time. This helps reduce context switching and promotes more collaboration.

Branching Strategy

Branch Types

Branch Purpose Naming Convention
main Active development branch –
<username>-<issue>-<desc> Feature or bugfix dyzhuu-123-add-login
release/* Release preparation release/v1.2.0
hotfix/* Critical fixes hotfix/v1.2.1

Rules

  1. Rebase your feature branch regularly
  2. Use squash merges into main
  3. Delete branches after they’re merged
  4. Do not force-push to shared branches

Code Review Guidelines

Before Submitting a Pull Request

  • Mark as a draft if not ready
  • Self-review for clarity, completeness, and formatting
  • Ensure all tests pass
  • Update any relevant documentation
  • Keep pull requests focused and manageable

Review Process

  1. Link the pull request to the relevant issue
  2. Request at least 2 reviewers, including the tech lead
  3. Respond to all feedback and engage in constructive discussion
  4. After 2 approvals, you may merge within 24 hours
  5. We use squash merging to keep history clean
  6. Announce major changes in the team chat

Collaboration Guidelines

  • Share progress and blockers during standups
  • Use GitHub issues and PR comments to communicate asynchronously
  • Review others’ code even if you didn’t write related features
  • Ask for help early and often
  • Offer help when others are stuck

Clone this wiki locally