team

Working Agreements

Definition of Ready, Definition of Done, team principles, branching strategy and role responsibilities. Agreed upon by all team members at project kickoff.

DoR

Definition of Ready

A backlog item is ready to be pulled into a sprint when all of the following are true:

User story is written and understood by the team

Acceptance criteria are defined and measurable

Data source / API access confirmed and format understood

Story is estimated (points assigned)

Dependencies identified and resolved or flagged

Technical approach discussed and agreed

Story is small enough to complete within one sprint

DoD

Definition of Done

A backlog item is done when all of the following are true:

✓

Code is written and committed to the repo

✓

Code reviewed by at least one other team member

✓

Pipeline runs end-to-end and data lands in the correct layer

✓

No known critical bugs

✓

README and inline comments updated

✓

Documentation updated (data dictionary, architecture diagram, etc.) when necessary

✓

Acceptance criteria met and verified

✓

Item moved to Done on the GitHub Project board

team principles — charter

Communication

—

Team communicates on a shared channel (Teams)

—

Blockers raised immediately — don't wait for the next meeting

—

Decisions documented in the Decisions & Open Questions Notion page

—

Personal time constraints are communicated ASAP, and the team plans around them.

Code

—

All code committed to the GitHub repo — no local-only scripts

—

Secrets never committed — always use .env files and GitHub Secrets

—

Branches used for features, PRs reviewed before merge to dev then main

—

Descriptive commit messages — reference issue number where relevant

Meetings

—

Weekly meeting with supervising teacher — every Friday

—

Prepare a brief status update before each meeting

—

Meeting minutes logged on the website after each session

—

Action items assigned to a named owner before end of meeting

Tasks

—

All work tracked as GitHub Issues — no invisible work

—

Issues assigned before starting work

—

Status updated on the board as work progresses

—

Carry-over items flagged explicitly at sprint review

git & branching strategy

main

Stable. Protected. Vercel deploys from here.

Never push directly — PR from dev only, 1 approval required.

dev

Integration branch. All issue branches merge here.

PR from issue branch required before merge.

feature/issue-N-short-description

One branch per GitHub Issue. Created from dev, merged back to dev.

Branch lives only for the duration of the issue.

Workflow

Pick an issue from the board, assign it to yourself

git checkout dev && git pull origin dev

git checkout -b feature/issue-N-description

Work and commit — reference issue: feat(#N): description

git push origin feature/issue-N-description

Open PR → dev on GitHub, request review

After review and merge, delete the branch

dev → main merged by lead dev at end of each sprint

Commit convention

feat(#N):

New feature or implementation

fix(#N):

Bug fix

etl(#N):

ETL or pipeline change

docs(#N):

Documentation only

chore(#N):

Config, deps, tooling

example

feat(#4): watchdog on SMB share for Jimmy

roles

Solution Architect

Architecture decisions, tool selection, scalability

Data Engineer

Ingestion, ETL, pipeline, storage, security

Data Analyst

OLAP model, BI dashboards, mockups, i18n

Data Scientist

ML models, feature engineering, predictions

signatures

By engaging with this project, all team members acknowledge and commit to the working agreements defined above.

Dehlyah

Solution Architect · Data Engineer

HES-SO Valais · 2026

Johann

Data Scientist · Data Analyst - Power BI

HES-SO Valais · 2026

Sacha

Data Engineer · BI (SAP SAC)

HES-SO Valais · 2026