Cérémonies Scrum Locales - KoproGo

Auteur:: KoproGo ASBL
Date:: 2025-01-15
Version:: 1.0
Statut:: Actif

Introduction 

Ce document décrit les cérémonies Scrum locales pratiquées par chaque équipe KoproGo (Backend, Frontend, Infra, IA/Grid).

Les cérémonies Scrum sont complétées par les événements Nexus (voir Nexus Framework pour KoproGo) pour la coordination cross-équipes.

Principes Scrum KoproGo 

Valeurs Scrum 

KoproGo applique les 5 valeurs Scrum :

Commitment : Équipes s’engagent sur Sprint Goal
Focus : Concentration sur Sprint Backlog (WIP limit)
Openness : Transparence (code, docs, décisions)
Respect : Code reviews bienveillantes, mentoring
Courage : Feedback honnête, remise en question

Adaptations ASBL 

Différences vs Scrum corporate :

Aspect	Scrum Standard	KoproGo ASBL
Équipe	Salariés full-time	Contributeurs bénévoles + salariés (futur)
Disponibilité	40h/semaine	Variable (5-20h/semaine)
Engagement	Contrat de travail	Contribution volontaire
Rôles	Fixes (PO, SM, Dev)	Rotatifs (SM, Tech Lead)
Réunions	Synchrones (bureau)	Asynchrones-first (distributed)

Conséquences :

Sprint planning flexible (participation asynchrone OK)
Daily Scrum écrit (Slack/GitHub) si pas dispo sync
Retro toujours synchrone (cohésion équipe)

Sprints KoproGo 

Durée et Cadence 

Durée sprint : 2 semaines (10 jours ouvrés)

Début : Lundi (Sprint Planning)

Fin : Vendredi soir (Sprint Review + Retro)

Calendrier type Sprint N :

Semaine 1:
- Lundi:    Sprint Planning (Nexus 4h, local 2h)
- Mardi-Vendredi: Daily Scrum (15 min/jour)

Semaine 2:
- Lundi-Jeudi: Daily Scrum (15 min/jour)
- Jeudi:   Backlog Refinement (1h, mid-sprint)
- Vendredi: Sprint Review (Nexus 2h) + Retro (Nexus 1h30)

Pas de sprint “0” : Dès le premier sprint, livrer increment déployable.

Sprint Goal 

Définition : Objectif court (1 phrase) du sprint, aligné avec Nexus Sprint Goal.

Critères bon Sprint Goal :

Concret : Décrit une fonctionnalité utilisateur (pas “refactoring”)
Testable : Critères acceptation clairs
Atteignable : Réaliste pour 2 semaines
Aligné Nexus : Contribue au Nexus Sprint Goal

Exemples :

❌ Mauvais Sprint Goal:
"Améliorer le code backend"
→ Vague, non testable

✅ Bon Sprint Goal (Backend):
"Implémenter workflow approbation factures (Draft → PendingApproval → Approved)"
→ Concret, testable (tests E2E), aligné Nexus

✅ Bon Sprint Goal (Frontend):
"UI responsive mobile pour liste factures + approbation (< 768px)"
→ Concret, testable (Playwright mobile), aligné Nexus

Affichage : GitHub Projects (custom field “Sprint Goal”)

Cérémonies Scrum Locales 

1. Sprint Planning (Local)

Objectif : Planifier travail équipe pour le sprint

Quand : Lundi matin (APRÈS Nexus Sprint Planning)

Durée : 2h

Participants : Équipe complète (3-5 devs + SM + optionnel PO)

Ordre du jour :

Part 1 : Quoi (1h) - Sélection items backlog

SM présente Nexus Sprint Goal + dépendances identifiées
Équipe sélectionne items top backlog (GitHub Projects)
Vérification critères “Ready” (voir Nexus Framework pour KoproGo)
Équipe formule Sprint Goal local (aligné Nexus)

Part 2 : Comment (1h) - Décomposition tâches

Équipe décompose chaque item en tâches techniques (< 1 jour)
Attribution tâches volontaire (pas imposée par SM !)
Identification risques techniques (POCs nécessaires ?)
Commit équipe sur Sprint Goal

Outputs :

Sprint Backlog (items + tâches GitHub Issues)
Sprint Goal affiché (GitHub Projects)
Vélocité cible (basée sur moyenne 3 derniers sprints)

Exemple Sprint Planning Backend (Sprint 12) :

Nexus Sprint Goal:
"Workflow factures avec approbation + monitoring production"

Sprint Goal Backend:
"API workflow factures (submit, approve, reject) + tests E2E + metrics Prometheus"

Items sélectionnés (28 points):
- #125: POST /expenses/:id/submit-for-approval (8 pts)
- #126: POST /expenses/:id/approve (5 pts)
- #127: POST /expenses/:id/reject (5 pts)
- #128: Tests E2E workflow complet (5 pts)
- #129: Prometheus metrics (expense_approvals_total) (5 pts)

Tâches #125 (exemple décomposition):
- [ ] Domain: Expense.submit_for_approval() (2h)
- [ ] Application: ExpenseUseCases.submit_for_approval() (3h)
- [ ] Infrastructure: POST handler (2h)
- [ ] Tests: Unit + integration (4h)
- [ ] Migration DB: add approved_by_id column (1h)

Risques:
- ⚠️ Email notification conseil syndical (dépend Infra SendGrid)
- ⚠️ Idempotence (submit multiple fois ?)

Attribution:
- Alice: #125, #128 (lead)
- Bob: #126, #127
- Charlie: #129 (Prometheus metrics)

2. Daily Scrum (Local)

Objectif : Synchroniser équipe, détecter blocages

Quand : Chaque jour ouvré, même heure (ex: 10h)

Durée : 15 min MAX (timebox strict)

Participants : Équipe dev uniquement (PO/SM optionnels observateurs)

Format : Debout (stand-up) ou écrit (Slack si async)

3 questions par dev :

Hier : Qu’ai-je terminé vers le Sprint Goal ?
Aujourd’hui : Que vais-je faire vers le Sprint Goal ?
Blocages : Qu’est-ce qui m’empêche d’avancer ?

Exemple Daily Scrum Backend (écrit, Slack) :

Alice:
- Hier: ✅ Domain Expense.submit_for_approval() + tests unit
- Aujourd'hui: Application layer ExpenseUseCases
- Blocages: Aucun

Bob:
- Hier: ✅ POST /expenses/:id/approve handler
- Aujourd'hui: Tests intégration PostgreSQL
- Blocages: ⚠️ Testcontainers lent (5 min startup)

Charlie:
- Hier: 🔨 Prometheus metrics (WIP)
- Aujourd'hui: Finaliser metrics + tests
- Blocages: ⚠️ Pas clair comment tester metrics (mock Prometheus ?)

Actions:
- Bob: Optimiser testcontainers (reuse containers between tests)
- Charlie: Pair avec Alice (elle a déjà testé metrics dans autre projet)

Règles Daily Scrum :

❌ PAS une réunion de status pour le SM/PO
❌ PAS de résolution problèmes (parking lot → après Daily)
✅ Focus Sprint Goal (pas “hier j’ai fait review PR #42”)
✅ Auto-organisation (équipe décide actions, pas SM)

Daily Scrum asynchrone (si contributeurs timezone différentes) :

Poster daily update dans Slack channel #backend-daily avant 10h
SM résume + partage blocages dans Nexus Daily Scrum
Résolution blocages : GitHub Issues (commentaires asynchrones)

3. Sprint Review (Local)

Objectif : Inspecter Increment, adapter backlog

Quand : Vendredi après-midi (AVANT Nexus Sprint Review)

Durée : 1h

Participants : Équipe + PO + stakeholders invités (optionnel)

Ordre du jour :

1. Rappel Sprint Goal (5 min)

SM rappelle Sprint Goal et vélocité cible vs réelle.

2. Démo Increment (30 min)

Équipe démontre items Done (respectant DoD).

Format démo :

Live coding (pas slides !)
Environnement staging (pas local)
Données réalistes (seed script)
Tests automatisés projetés (démo TDD)

Exemple démo Backend Sprint 12 :

Démo API workflow factures:

1. cURL POST /expenses (création facture Draft)
2. cURL POST /expenses/:id/submit-for-approval
   → Retour 200, state = PendingApproval
   → Email SendGrid envoyé (montré dans logs)
3. cURL POST /expenses/:id/approve
   → Retour 200, state = Approved
4. Tests E2E Cucumber (projeté terminal):
   ✅ Scenario: Submit expense for approval
   ✅ Scenario: Approve expense
   ✅ Scenario: Reject expense
5. Grafana dashboard Prometheus:
   → Métrique expense_approvals_total = 1

3. Feedback stakeholders (15 min)

PO/stakeholders posent questions, suggèrent améliorations.

4. Mise à jour backlog (10 min)

PO ajuste backlog selon feedback (nouveaux items, re-priorisation).

Outputs :

Increment déployé staging
Vélocité réelle (points Done)
Backlog ajusté

Note : Sprint Review local ≠ Nexus Sprint Review (cross-équipes)

4. Sprint Retrospective (Local)

Objectif : Améliorer processus équipe

Quand : Vendredi après-midi (AVANT Nexus Sprint Retrospective)

Durée : 1h

Participants : Équipe dev + SM (PO optionnel si invité)

Règle d’or : Safe space (confidentialité, bienveillance, pas de blâme)

Format : Varie chaque sprint (exemples ci-dessous)

Format 1 : Start/Stop/Continue

Équipe brainstorm (10 min silencieux, post-its) :

Start : Quoi commencer à faire ?
Stop : Quoi arrêter de faire ?
Continue : Quoi continuer (fonctionne bien) ?

Vote dot (5 dots/personne) → Top 3 actions

Exemple Retro Backend Sprint 12 :

START:
- Pair programming pour features complexes (8 votes) ✅
- Benchmarks systématiques (Criterion) (3 votes)

STOP:
- Meetings après 17h (trop tard, fatigue) (7 votes) ✅
- PRs > 500 lignes (trop longues à reviewer) (6 votes) ✅

CONTINUE:
- Tests BDD Cucumber (super lisibles) (5 votes)
- Async daily Slack (timezone-friendly) (4 votes)

Top 3 actions Sprint 13:
1. ✅ Pair programming 2h/semaine (Alice + Bob, Charlie + nouveau)
2. ✅ Meetings max 16h30 (sauf urgence)
3. ✅ PRs max 300 lignes (split si plus gros)

Format 2 : Timeline

Dessiner timeline sprint (15 jours), équipe ajoute émotions (😀😐😞) + événements clés.

Exemple :

Jour 1 (Lundi): 😀 Sprint planning clair
Jour 3 (Mercredi): 😞 Testcontainers cassé (CI rouge)
Jour 5 (Vendredi): 😐 PR review lente (48h attente)
Jour 8 (Lundi S2): 😀 Testcontainers fixé (Bob hero!)
Jour 10 (Mercredi S2): 😀 Feature terminée early
Jour 12 (Vendredi S2): 😐 Stress demo (peur bugs)

Discussion: Pourquoi stress demo ?
→ Pas de tests staging avant
→ Action: Déployer staging J-1 demo (jeudi soir)

Format 3 : Glad/Sad/Mad

Glad : Content de quoi ?
Sad : Déçu de quoi ?
Mad : Frustré par quoi ?

Outputs Retro :

2-3 actions concrètes Sprint N+1 (SMART: Specific, Measurable, Atteignable)
Actions trackées GitHub Issues (label retro-action)
Review actions précédentes (Done ? Si non, pourquoi ?)

Facilitation Retro :

SM facilite (neutre, pas défensif)
Timeboxing strict (1h max)
Parking lot (sujets hors scope → GitHub Discussions)
Rotation facilitateur (équipe mature → dev peut faciliter)

Rôles Scrum 

Product Owner (PO)

Responsabilités :

Définir vision produit (alignée TOGAF ADM)
Maintenir Product Backlog (priorisation)
Rédiger user stories (critères acceptation)
Accepter/rejeter Increment (Sprint Review)
Disponible pour équipe (questions, clarifications)

Chez KoproGo :

PO unique pour tout KoproGo (cross-équipes)
Membre CA ASBL (légitimité gouvernance)
Disponibilité : 20h/semaine minimum
Rotation possible (vote CA, mandat 1 an)

Profil PO idéal :

Connaissance métier copropriétés (syndic, comptable, ou juriste)
Compétences techniques (comprendre faisabilité)
Capacité décision (pas consensus permanent)

Scrum Master (SM)

Responsabilités :

Faciliter cérémonies Scrum
Résoudre blocages équipe
Protéger équipe (interruptions, scope creep)
Coaching Scrum (valeurs, pratiques)
Amélioration continue (retros, metrics)

Chez KoproGo :

SM par équipe (4 SMs : backend, frontend, infra, IA)
Contributeur senior (lead dev OK si double casquette)
Rotation conseillée (6 mois → mentoring)

Profil SM idéal :

Certification Scrum (PSM I minimum, recommandé)
Expérience dev (crédibilité technique)
Soft skills (écoute, empathie, facilitation)

Development Team 

Responsabilités :

Livrer Increment Done chaque sprint
Auto-organisation (qui fait quoi)
Qualité code (tests, reviews, refactoring)
Respect DoD (non négociable)
Collaboration (pair programming, mentoring)

Taille équipe : 3-5 devs (idéal Scrum)

Compétences cross-fonctionnelles :

Chaque dev = T-shaped (expertise 1 domaine + connaissances larges)
Exemple Backend : Expert Rust + notions PostgreSQL + notions DevOps

Chez KoproGo :

Contributeurs bénévoles (majorité, phase ASBL)
Salariés part-time/full-time (future, phase Coopérative)
Onboarding : Pair 1 semaine avec senior (code + culture)

Definition of Done (DoD)

DoD Équipe (complète DoD Nexus)

Voir Nexus Framework pour KoproGo pour DoD Nexus (cross-équipes).

DoD Backend (ajoute à Nexus) :

✅ Architecture hexagonale respectée (Domain → Application → Infrastructure)
✅ Migrations DB testées (rollback + rollforward)
✅ Benchmarks Criterion (si endpoint perf-critical)
✅ Docs Rust (cargo doc comments)

DoD Frontend (ajoute à Nexus) :

✅ Responsive mobile (Playwright tests < 768px)
✅ Accessibilité WCAG 2.1 AA (axe-core scans)
✅ PWA offline (ServiceWorker cache)
✅ Storybook components (future)

DoD Infra (ajoute à Nexus) :

✅ Terraform plan OK (dry-run, no surprises)
✅ Ansible idempotent (run 2x = same result)
✅ Runbook SRE (incident response doc)
✅ Rollback plan (max 5 min downtime)

DoD IA/Grid (ajoute à Nexus) :

✅ Tests edge ARM64 (Raspberry Pi)
✅ Modèle quantized (< 2GB RAM)
✅ Benchmarks inference (< 100ms P99)
✅ Revenus compute trackés (blockchain future)

Métriques Scrum Locales 

Vélocité Équipe 

Définition : Story points Done par sprint

Calcul : Somme points items Done (respectant DoD)

Objectif : Stabilité (± 10% sprint N vs N-1)

Exemple Backend Sprints 10-12 :

Sprint 10: 20 points
Sprint 11: 18 points
Sprint 12: 22 points
Moyenne: 20 points ± 2 (stable ✅)

Usage :

Sprint Planning : Sélectionner ~20 points (basé moyenne)
PO : Prévoir roadmap (ex: Feature 60 pts = 3 sprints)

Anti-pattern :

❌ Vélocité = KPI performance équipe (pression → inflation points)
✅ Vélocité = outil planification (prévisibilité)

Burndown Chart 

Définition : Graphique story points restants vs jours sprint

Axes :

X : Jours sprint (0 à 10)
Y : Story points restants

Ligne idéale : Diagonale (progression linéaire)

Exemple Sprint 12 Backend :

Jour 0:  28 points (Sprint Planning)
Jour 2:  28 points (pas Done encore)
Jour 4:  20 points (item #125 Done, 8 pts)
Jour 6:  15 points (item #126 Done, 5 pts)
Jour 8:  10 points (item #127 Done, 5 pts)
Jour 10:  0 points (tous items Done ✅)

Alarmes :

Courbe flat (pas de progrès) → Daily focus blocages
Courbe monte (scope creep) → PO protège Sprint Goal

Cycle Time 

Définition : Temps entre “In Progress” et “Done” (1 item)

Objectif : < 3 jours (idéal 1-2 jours)

Exemple :

Item #125:
- Lundi 10h: In Progress
- Mercredi 16h: Done
→ Cycle time: 2,25 jours ✅

Alarmes :

Cycle time > 5 jours → Item trop gros (décomposer)
Cycle time > 7 jours → Blocage (SM investigate)

Code Review Time 

Définition : Temps entre “PR created” et “PR merged”

Objectif : < 24h (1 working day)

Règles KoproGo :

PR < 300 lignes : 2h review max
PR 300-500 lignes : 4h review max
PR > 500 lignes : ❌ Refus (split required)

Exemple :

PR #234:
- Mardi 14h: Created (250 lignes)
- Mardi 16h: Review Alice (approve)
- Mardi 17h: Review Bob (request changes)
- Mercredi 10h: Changes pushed
- Mercredi 11h: Bob approve
- Mercredi 11h30: Merged
→ Review time: 21h30 ✅

Alarmes :

Review time > 48h → Reviewer overload (assign 2nd reviewer)

Outils Scrum 

GitHub Projects 

Board Kanban : https://github.com/users/gilmry/projects

Colonnes :

Backlog : Items priorités (PO), triés top → bottom
Sprint N : Items sprint en cours
In Progress : WIP (limit 2 items/dev)
Review : Attente code review
Done : Merged + déployé staging

Automation GitHub :

Issue created → Backlog
PR opened → Review
PR merged → Done (auto)

Custom Fields :

Sprint Goal (texte)
Story Points (nombre Fibonacci)
Team (select: backend/frontend/infra/ia)
Priority (select: P0/P1/P2/P3)

Estimation : Planning Poker 

Échelle Fibonacci : 1, 2, 3, 5, 8, 13, 21

Signification :

1 pt : Trivial (< 2h, ex: typo fix)
2 pts : Simple (< 4h, ex: add DB column)
3 pts : Moyen (1 jour, ex: CRUD endpoint)
5 pts : Complexe (2 jours, ex: workflow feature)
8 pts : Très complexe (3-4 jours, ex: auth system)
13 pts : Epic (1 semaine, décomposer !)
21+ pts : ❌ Trop gros (obligatoire split)

Processus Planning Poker :

PO lit user story + critères acceptation
Équipe pose questions (5 min max)
Chaque dev vote simultanément (cartes/app)
Si consensus (± 1 pt) → Estimation validée
Si divergence (ex: 2 vs 8) → Discuss extremes, re-vote

Exemple :

Item: "Implémenter POST /expenses/:id/approve"

Vote 1:
- Alice: 3 pts
- Bob: 8 pts
- Charlie: 5 pts

Discussion:
- Bob: "Il faut workflow state machine + email notification"
- Alice: "Email déjà fait Infra, juste call API"
- Charlie: "State machine = pattern Strategy, 1 jour"

Vote 2:
- Alice: 5 pts
- Bob: 5 pts
- Charlie: 5 pts

✅ Consensus: 5 points

Tests & Qualité 

Stratégie Pyramid 

KoproGo applique Test Pyramid :

         E2E (10%)
        /        \
      /            \
    /   Integration  \
  /       (30%)        \
/__________________________\
       Unit (60%)

Répartition temps tests :

60% Unit : Domain logic, use cases (fast, isolés)
30% Integration : Repositories PostgreSQL (testcontainers)
10% E2E : Full workflow API → UI (Playwright, Cucumber)

Exemple Backend Sprint :

Sprint 12 (5 jours dev):
- 3 jours: Feature code + unit tests (60%)
- 1,5 jours: Integration tests PostgreSQL (30%)
- 0,5 jours: E2E tests Cucumber (10%)

TDD (Test-Driven Development)

Pratique recommandée (pas obligatoire) :

Red : Écrire test qui fail
Green : Code minimal pour passer test
Refactor : Améliorer code (tests stay green)

Exemple TDD Backend :

// 1. RED: Test fail (fonction n'existe pas)
#[test]
fn test_submit_expense_for_approval() {
    let expense = Expense::new_draft(...);
    let result = expense.submit_for_approval();
    assert!(result.is_ok());
    assert_eq!(expense.state, ExpenseState::PendingApproval);
}

// 2. GREEN: Implémentation minimale
impl Expense {
    pub fn submit_for_approval(&mut self) -> Result<(), String> {
        self.state = ExpenseState::PendingApproval;
        Ok(())
    }
}

// 3. REFACTOR: Ajouter validations
impl Expense {
    pub fn submit_for_approval(&mut self) -> Result<(), String> {
        if self.state != ExpenseState::Draft {
            return Err("Can only submit Draft expenses".to_string());
        }
        self.state = ExpenseState::PendingApproval;
        self.submitted_at = Some(Utc::now());
        Ok(())
    }
}

Avantages TDD :

Design code testable (dependency injection forcée)
Coverage 100% (tests écrits first)
Refactoring safe (tests = safety net)

BDD (Behavior-Driven Development)

Outil : Cucumber (Gherkin syntax)

Usage : Tests E2E user-facing features

Exemple :

# backend/tests/features/expense_workflow.feature

Feature: Expense Approval Workflow
  As a syndic, I want to submit expenses for approval
  So that conseil syndical can review before payment

Scenario: Submit expense for approval
  Given a building "Résidence Mozart" exists
  And an expense "Plumbing repair" in Draft state
  When the syndic submits the expense for approval
  Then the expense state is "PendingApproval"
  And an email is sent to conseil syndical members
  And the audit log records "Submitted by syndic@example.com"

Run tests BDD :

cd backend && cargo test --test bdd

Avantages BDD :

Lisible non-devs (PO, stakeholders)
Documentation vivante (tests = specs)
Focus comportement utilisateur (pas implémentation)

Voir aussi 

Nexus Framework pour KoproGo : Coordination cross-équipes
TOGAF ADM pour KoproGo ASBL : Architecture d’entreprise
KoproGo - Roadmap par Capacités : Roadmap par jalons
🎥 Guide Complet des Tests E2E : Guide tests E2E Playwright
🛠️ Guide des Commandes Make : Commandes tests (make test, test-bdd, etc.)

—

Document maintenu par KoproGo ASBL - Scrum adapté pour l’open-source et contributeurs bénévoles