Team Info

Team Delivery Framework

This document consolidates the core engineering practices, conventions, and working agreements that guide our team’s delivery process for the Forests Client Management System. As the project has evolved, this wiki serves as the single source of truth for how we plan, estimate, categorize, and execute work.

Here you’ll find our shared guidelines on:

• Sprint structure and cadence
• Scrum ceremonies and expectations
• Story point estimation and sizing
• Definition of Done / Acceptance Criteria
• Developer contract (linting, minimum 80% coverage, Conventional Commits, small PRs)

---

Scrum Overview

Our team follows a lightweight, practical interpretation of Scrum. We use Scrum not as a rigid rulebook, but as a framework that helps us:

• Deliver value incrementally: Work is decomposed into manageable, deployable increments.
• Maintain a predictable cadence: Predictable iterations allow our stakeholders and product owners to align expectations.
• Collaborate across disciplines: Designers, developers, QA analysts, and business owners jointly own product outcomes.
• Inspect and adapt: Every sprint provides an opportunity to reflect and refine our processes.

---

Sprint Structure

We work in three-week sprints, a cadence chosen to balance meaningful engineering delivery with adequate time for discovery, refinement, user feedback, and testing. Each sprint includes four core ceremonies:

1. Sprint Planning

• Held at the start of each sprint.
• The team reviews the prioritized backlog, clarifies acceptance criteria, and commits to a realistic set of deliverables.
• Story point estimates and acceptance criteria must be agreed upon before work begins.

2. Daily Standups

• Short, focused daily check-ins (15 minutes).
• Each team member shares progress since yesterday, planned tasks for today, and any blockers.
• The emphasis is on team alignment and identifying obstacles early, not formal status reporting.

3. Sprint Review (with Stakeholders & Users)

• Demonstration of completed features and enhancements to product owners, forestry domain experts, and ministry users.
• Provides immediate validation of design and implementation choices, surfacing adjustments early.

4. Sprint Retrospective

• Internal team reflection on what went well, what caused friction, and what concrete steps we will take to improve.
• Action items are tracked and carried into the next sprint.

---

Story Point Estimation Guidelines

Story point estimation is a core practice in our delivery workflow. Points represent relative complexity, effort, and uncertainty, not absolute wall-clock hours.

Purpose of Story Point Estimates

Estimates help the team:

• Develop a shared, cross-functional understanding of the work.
• Uncover technical unknowns, integration risks, and unstated assumptions before coding starts.
• Plan sprints with realistic velocity and commitments.
• Facilitate conversations that create alignment.

Estimation Scale (Fibonacci)

Story Points	Approximate Effort	Typical Meaning
1	1 hour to half a day	Very small, low-risk, well-understood task (e.g., config tweak, typo fix, simple unit test).
2	~1 full day	Straightforward task with minimal uncertainty (e.g., adding an input field with existing validation).
3	1–3 days	Moderate complexity, multiple components involved, or minor external unknowns.
5	~1 week	Substantial effort with multiple moving parts (e.g., new form step, new API endpoint + DB schema change).
8	Full sprint	Very large feature; high complexity; should be refined or split if possible.

Handling Items Larger Than 8 Points

Any backlog item estimated at greater than 8 story points must be decomposed into smaller, well-defined stories before entering an active sprint. Tasks of this scale typically indicate:

• Hidden technical dependencies or architectural unknowns.
• Multiple logical deliverables bundled together.
• High risk of carry-over across sprint boundaries.

Decomposing epics into smaller stories ensures continuous flow, clearer testing boundaries, and predictable releases.

Definition of Done & Acceptance Criteria

Every estimated backlog item must satisfy:

1. Clear Acceptance Criteria: Specific, verifiable conditions that must be true for the feature to be considered complete.
2. Definition of Done (DoD):
   • Code builds without warnings or errors.
   • Linting rules pass cleanly.
   • Unit tests pass with at least 80% code coverage for new or modified logic.
   • Integration and Cypress E2E tests pass where applicable.
   • Code is reviewed and approved by at least one peer.
   • Corresponding documentation in the repository or wiki is updated.

---

Developer Contract

To maintain high standards of quality, consistency, and long-term maintainability, all team members adhere to our Developer Contract:

1. Code Quality & Linting

• All code must pass ESLint and Prettier checks (frontend) and Google Java Style checks (backend) prior to opening a PR.
• Automated linting runs on every commit in CI (.github/workflows/analysis.yml).

2. Minimum 80% Test Coverage

• We enforce a minimum threshold of 80% test coverage for all new or modified code.
• Coverage reports are generated automatically by Vitest (frontend) and JaCoCo (backend) and verified by SonarCloud.
• Tests should focus on meaningful business logic, edge cases, and error-handling paths.

3. Conventional Commits

All Git commit messages must follow the Conventional Commits specification:

<type>(<scope>): <short summary>

[optional body]

[optional footer(s)]

Common types:

• feat: A new user-facing feature or API capability.
• fix: A bug fix.
• docs: Documentation only changes.
• style: Formatting, whitespace, or lint fixes without logic changes.
• refactor: Code reorganization that neither fixes a bug nor adds a feature.
• test: Adding or correcting tests.
• chore: Tooling, build scripts, or dependency updates.

4. Living Documentation

• Documentation is treated as a first-class product deliverable.
• Any architectural change, new environment variable, new API endpoint, or UI change must be accompanied by an update to the corresponding README.md or wiki page.

5. Small, Focused Pull Requests

• Keep PRs focused on a single responsibility.
• Include a descriptive PR summary explaining why the change is needed and how it was tested.
• Link the relevant GitHub Issue or Jira ticket.