Gestion de projet agile : Scrum pour équipes africaines

Ce que vous saurez faire à la fin

1. Mettre en place un Scrum complet en 4 semaines avec une équipe distante.
2. Choisir et configurer Jira, Trello ou Linear pour piloter votre backlog.
3. Animer Sprint Planning, Daily, Review, Rétro avec des time-box stricts.
4. Estimer en story points avec planning poker.
5. Mesurer la vélocité et améliorer l’équipe sprint après sprint.

Durée : Cycle d’apprentissage de 6 sprints (12 semaines). Pré-requis : équipe de 4 à 9 personnes, Product Owner identifié, Scrum Master (peut être à mi-temps), outil de gestion (Jira, Linear, Trello), espace digital (Slack ou Teams), café.

Étape 1 — Comprendre les 3 rôles Scrum

Étape 2 — Choisir et configurer votre outil

Pour démarrer : Trello (gratuit, simple). Pour scale : Linear (10 $/user/mois, ultra-rapide) ou Jira (8 $/user/mois, robuste). Configurez :

Statuts : Backlog → To Do → In Progress → Review → Done
Champs custom : Story Points, Sprint, Epic, Priority
Filtres : "Mon sprint", "À review", "Bloqué"
Boards : 1 par équipe Scrum

Étape 3 — Construire le Product Backlog

Format des items (User Stories) :

En tant que [rôle utilisateur]
Je veux [action]
Afin de [bénéfice]

Critères d'acceptation :
- Étant donné [contexte]
- Quand [action]
- Alors [résultat attendu]

Exemple : « En tant que client, je veux payer en Wave depuis le checkout, afin d’éviter d’entrer ma carte. » Le PO maintient le backlog ordonné par valeur.

Étape 4 — Estimer en story points avec Planning Poker

Suite de Fibonacci modifiée : 1, 2, 3, 5, 8, 13, 21. 1 = trivial. 21 = à découper. L’équipe estime ensemble : (1) PO présente l’item, (2) chacun choisit une carte (Planning Poker app gratuite), (3) on retourne en même temps, (4) si écart, les extrêmes argumentent, (5) on revote jusqu’à convergence.

Étape 5 — Tenir le Sprint Planning (4h pour sprint de 2 semaines)

1. Partie 1 (2h) : PO présente le top du backlog, équipe pose questions, sélectionne ce qu’elle s’engage à livrer (en fonction de la vélocité passée).
2. Partie 2 (2h) : équipe découpe les stories en tâches techniques (max 1 j chacune), assigne les premières.

Sortie : Sprint Goal en 1 phrase + Sprint Backlog figé.

Étape 6 — Animer le Daily Stand-up (15 min strict)

Tous les jours à la même heure (9h05). Debout (en présentiel) ou caméra ouverte (distant). Chacun répond :

1. Hier, j'ai fait...
2. Aujourd'hui, je vais...
3. J'ai un blocage : ...

Pas de débat technique, c’est noté pour après. Pas de status pour le manager : pour l’équipe. Time-box stricte 15 min, sinon on dérive.

Étape 7 — Tenir la Sprint Review (1h)

Démo de ce qui a été fait. Présents : équipe + PO + stakeholders (clients internes, direction). Format :

1. 5 min — résumé du Sprint Goal
2. 40 min — démo live des fonctionnalités, pas de slides
3. 15 min — feedback stakeholders, ajustements backlog

Pas de présentation de ce qui n’est PAS terminé. Honnêteté sur les engagements non tenus.

Étape 8 — Tenir la Rétrospective (1h)

Format « Continue / Stop / Start » sur Whimsical ou Mural :

Continue : ce qui marche, à conserver
Stop     : ce qui plombe, à arrêter
Start    : ce qu'on aimerait essayer

Étapes :
1. 10 min — chacun écrit ses post-it (silencieusement)
2. 15 min — on lit, on regroupe par thème
3. 15 min — vote (3 stickers par personne sur les sujets prioritaires)
4. 20 min — on discute les 3 sujets gagnants
5. Sortie : 1-3 actions concrètes pour le sprint suivant

Étape 9 — Mesurer la vélocité sur 6 sprints

Vélocité = somme des story points livrés (statut Done) par sprint. Tracez sur un graphique en barres. Au bout de 3-4 sprints, la vélocité se stabilise (± 20 %). Utilisez la moyenne des 3 derniers sprints pour engager le sprint suivant. Si vélocité chute brutalement : retour en rétro pour comprendre.

Étape 10 — Construire un Burndown Chart

Graphe des story points restants par jour de sprint. Ligne idéale : descente linéaire. Si la courbe reste plate, c’est qu’on n’avance pas (alerte rouge dès J+3). Outils : natif dans Jira / Linear, ou Sheets manuel pour Trello.

Étape 11 — Définir la Definition of Done

Critères que CHAQUE story doit cocher pour passer en Done :

□ Code écrit et review par 1 pair
□ Tests unitaires écrits, passants
□ Tests E2E passants
□ Doc mise à jour (README, API)
□ Déployé en staging
□ Démo'd au PO et accepté
□ Pas de bug bloquant connu

Affichez la DoD dans le board. Sans DoD claire, « Done » devient « presque fini ».

Étape 12 — Adapter Scrum à une équipe distribuée Afrique

Spécificités :

• Daily à 9h00 GMT (couvre Dakar, Abidjan, Bamako, Cotonou, Casa)
• Sprint Planning 14h pour ne pas aligner sur déjeuner
• Coupure électrique : prévoir batterie laptop chargée + 4G backup
• Wifi instable : caméra optionnelle, micro toujours ON pour engagement
• Asynchrone first : décisions documentées dans Slack + lien dans le ticket

Étape 13 — Gérer les bugs critiques en cours de sprint

Réservez 10-20 % de la capacité sprint pour les bugs production (slack capacity). Si un bug critique arrive : (1) PO décide go/no-go en 30 min, (2) si go, une story sort du sprint en échange, (3) on documente dans le journal sprint. Si bugs critiques > 20 % : il y a un problème de qualité à traiter en rétro.

Étape 14 — Faire monter en maturité l’équipe

4 niveaux à atteindre :

1. Mois 1-3 : Application stricte du framework
2. Mois 4-6 : Adaptation aux contraintes locales
3. Mois 7-12 : Auto-organisation forte, Scrum Master à mi-temps
4. An 2+ : Hybride Kanban / Scrum, prédictibilité > 80 %

Erreurs Scrum classiques

• Sprint Planning de 30 min : on n’a pas le temps de découper, sprint chaotique.
• Daily comme reporting au manager : tue l’engagement de l’équipe.
• Pas de rétro : les mêmes problèmes reviennent sprint après sprint.
• Estimer en heures au lieu de story points : faux sentiment de précision.
• PO absent ou multi-projets : backlog mal priorisé, équipe sans cap.

Checklist Scrum équipe africaine

✓ 3 rôles attribués nominativement
✓ Outil configuré (Trello / Linear / Jira)
✓ Backlog initial avec 30+ stories format US
✓ Définition of Done écrite et affichée
✓ Sprint Planning 4h calé bi-hebdo
✓ Daily 15 min strict, même créneau
✓ Sprint Review 1h avec démo live
✓ Rétro 1h avec actions concrètes
✓ Vélocité mesurée et stable (3 sprints)
✓ Burndown chart à jour
✓ Buffer 10-20 % bugs prod
✓ Décisions documentées en async (Slack)
✓ Audit maturité tous les 6 sprints