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

Étape 1 : aligner l’équipe sur la cadence Scrum avant le premier sprint

Avant d’écrire la moindre user story, l’équipe doit partager le même vocabulaire et la même cadence. Une équipe à Dakar, Abidjan, Cotonou ou Douala a souvent des contraintes différentes d’une équipe européenne : électricité instable, fuseau horaire flottant côté client, devises mixtes (XOF, XAF, EUR à 655,957 FCFA, USD), connexions inégales selon les quartiers. Le rituel Scrum doit s’adapter sans renier ses principes.

Réunissez les développeurs, le Product Owner et le Scrum Master pendant 90 minutes. Posez par écrit la durée du sprint (1 ou 2 semaines, jamais 4), les heures du Daily, le créneau de la Revue et de la Rétrospective. Validez ensemble que ces créneaux respectent les heures de prière du vendredi pour les équipes mixtes et qu’ils tombent en dehors des coupures SENELEC ou CIE connues.

# Exemple de cadence consignée dans le README du dépôt
Sprint : 2 semaines (lundi 09h00 → vendredi 17h00 GMT)
Daily Scrum : 09h15, max 15 minutes, en visio + WhatsApp fallback
Revue Sprint : vendredi 14h00 (démo client)
Rétrospective : vendredi 16h00, en français
Definition of Done : tests verts, code review approuvée, déployé staging

Affichez ce bloc dans le canal Slack ou WhatsApp Business du projet. Le test concluant : à la question « quand est le prochain Daily ? », chaque membre répond la même heure sans hésiter. Si quelqu’un hésite, recommencez la cérémonie d’alignement avant de lancer le sprint zéro.

Étape 2 : construire un Product Backlog priorisé pour le marché ouest-africain

Le Product Backlog est la colonne vertébrale du projet. Sans priorisation rigoureuse, l’équipe gaspille les sprints sur des fonctionnalités secondaires. La méthode MoSCoW (Must, Should, Could, Won’t) reste la plus simple à expliquer à un client habitué aux cahiers des charges figés.

Listez chaque exigence sous forme de user story : « En tant que [rôle], je veux [action] afin de [bénéfice] ». Pour un projet de fintech à Dakar, une story typique sera : « En tant que commerçant, je veux encaisser via Wave et Mixx by Yas afin d’éviter le cash le vendredi soir ». Ajoutez systématiquement des critères d’acceptation mesurables.

# Exemple de user story dans Jira ou ClickUp
Titre : Paiement Wave intégré au tunnel de commande
En tant que : client final à Pikine
Je veux : payer ma commande via Wave en moins de 30 secondes
Afin de : éviter de saisir un numéro de carte
Critères d'acceptation :
- Le bouton Wave apparaît si total > 500 FCFA
- Le webhook de confirmation est reçu en moins de 10 secondes
- Un échec affiche un message en français + bouton « réessayer »
- Le ticket de caisse mentionne le wallet utilisé

Le Product Owner classe ensuite les stories par valeur business. Un signal de réussite : les 10 stories du haut représentent au moins 60 % de la valeur perçue par le client. Si la priorisation est diffuse, refaites une session avec le client présent.

Étape 3 : organiser le Sprint Planning malgré les contraintes réseau

Le Sprint Planning dure deux heures pour un sprint de deux semaines. Dans une équipe distribuée Dakar–Abidjan–Paris, la qualité du lien internet conditionne l’efficacité. Prévoyez une bande passante minimum de 2 Mbps par participant et un canal de secours.

Démarrez la réunion en partageant l’écran avec le Backlog. Le Product Owner présente les stories candidates, les développeurs estiment en Story Points via Planning Poker (cartes 1, 2, 3, 5, 8, 13, 21). L’estimation se fait à main levée, jamais sous pression du client.

# Outil gratuit recommandé : planningpokeronline.com
1. Créer une room privée
2. Inviter via lien (pas besoin de compte)
3. Chaque dev choisit sa carte simultanément
4. Discuter les écarts > 5 points
5. Re-voter jusqu'au consensus

Le sprint est verrouillé quand la somme des Story Points ne dépasse pas la vélocité moyenne des trois derniers sprints. Pour une nouvelle équipe, démarrez prudemment à 20 points sur deux semaines. Comment vérifier le bon fonctionnement : aucun développeur ne quitte la salle en disant « je ne sais pas ce que je dois faire lundi matin ».

Étape 4 : tenir le Daily Scrum en 15 minutes chrono, même en visio dégradée

Le Daily Scrum est le rituel le plus saboté dans les équipes africaines distribuées. Coupures de courant, latence Zoom, retard de transport, tout pousse à le rallonger ou à le sauter. Discipline obligatoire : 15 minutes, debout si présentiel, caméras allumées si visio.

Trois questions par personne, dans cet ordre strict : qu’ai-je terminé hier, que ferai-je aujourd’hui, quels obstacles me bloquent. Le Scrum Master note les obstacles dans un canal dédié et les résout en dehors du Daily.

# Modèle de message WhatsApp si la visio tombe
[Daily 09h15] Aïssatou
Hier : terminé l'API /transactions
Aujourd'hui : tests unitaires + intégration Wave
Obstacle : sandbox Wave en panne depuis 06h00, ticket support ouvert

Le test concluant : le Daily se termine en moins de 15 minutes 9 fois sur 10. Si vous dépassez régulièrement, c’est que des discussions techniques s’incrustent. Coupez et déplacez-les vers un canal asynchrone ou une réunion de 30 minutes après le Daily.

Étape 5 : gérer les obstacles spécifiques au contexte ouest-africain

Les obstacles ne sont pas que techniques. Une coupure SENELEC de 4 heures, un délai de virement bancaire BCEAO, un retard de livraison d’un serveur depuis Abidjan, ces réalités ralentissent l’équipe. Le Scrum Master doit les anticiper.

Tenez un journal des obstacles avec date, type, durée, action. Au bout de trois sprints, vous identifierez des patterns récurrents et pourrez investir dans une solution structurelle : onduleur 1500 VA, abonnement double FAI (Orange + Free), poste de secours chez un membre de l’équipe.

# Modèle de journal Markdown
| Date       | Obstacle                        | Durée | Action prise              |
|------------|---------------------------------|-------|---------------------------|
| 2026-04-12 | Coupure SENELEC quartier Mermoz | 3h    | Bascule chez Mor (Sicap)  |
| 2026-04-15 | Lenteur sandbox Mixx by Yas     | 4h    | Mocks locaux activés      |
| 2026-04-18 | Délai virement BCEAO Wave→banque| 24h   | Avance sur trésorerie     |

Vous saurez que tout fonctionne quand : le journal contient au moins 5 entrées par sprint et chacune a une action correspondante. Si la colonne Action est vide, l’équipe subit ses obstacles au lieu de les résoudre.

Étape 6 : conduire la Revue de Sprint avec le client en présentiel ou en visio

La Revue de Sprint dure une heure pour deux semaines de travail. C’est le moment où l’équipe démontre l’incrément au Product Owner et aux parties prenantes. Pour un client à Dakar, privilégiez le présentiel le vendredi après-midi, café et thé attiéké à l’appui.

Préparez une démo scénarisée, jamais improvisée. Un développeur conduit, les autres observent. Le Product Owner valide story par story selon les critères d’acceptation définis à l’étape 2. Toute story incomplète retourne au Backlog, sans négociation.

# Checklist avant la démo
[ ] Environnement staging à jour
[ ] Données de test cohérentes (FCFA, noms locaux)
[ ] Connexion 4G de secours testée
[ ] Slides de contexte (3 max) prêtes
[ ] Lien de feedback partagé en fin de revue

Vous saurez que tout fonctionne quand : le client repart avec une vision claire de ce qui a été livré, et donne un feedback exploitable pour le prochain sprint. Si le client dit « c’est bien » sans détails, vous avez raté la revue.

Étape 7 : exploiter la Rétrospective pour amélioration continue

La Rétrospective dure une heure et reste le rituel le plus négligé. Pourtant, c’est là que l’équipe gagne en maturité. Format simple : Mad / Sad / Glad. Chaque membre écrit trois post-it, on regroupe, on vote, on choisit deux actions concrètes pour le prochain sprint.

Utilisez un Miro, un FigJam ou un tableau blanc physique. La règle d’or : aucune attaque personnelle, on parle du processus, pas des personnes. Le Scrum Master facilite, ne juge pas.

# Exemple d'actions issues d'une rétro
Action 1 : automatiser le déploiement staging (responsable : Mor, échéance : sprint+1)
Action 2 : ajouter un canal #obstacles dédié dans Slack (responsable : Aïssatou)

Voir aussi notre guide pour lancer une startup SaaS à Dakar où la méthodologie agile est appliquée de bout en bout. Le marqueur de succès : à la rétro suivante, les deux actions précédentes sont marquées « faites » ou « en cours réel ».

Étape 8 : mesurer la vélocité et ajuster sur 5 sprints

La vélocité est la moyenne des Story Points livrés par sprint. Elle se stabilise après cinq sprints. Avant cela, ne tirez aucune conclusion. Tracez la courbe dans un Google Sheet partagé avec le client.

# Modèle de calcul
Sprint 1 : 18 pts engagés, 14 livrés
Sprint 2 : 18 pts engagés, 17 livrés
Sprint 3 : 20 pts engagés, 19 livrés
Sprint 4 : 22 pts engagés, 21 livrés
Sprint 5 : 22 pts engagés, 22 livrés
Vélocité = (14+17+19+21+22) / 5 = 18,6 pts

Indicateur que tout est en place : la vélocité varie de moins de 15 % d’un sprint à l’autre. Si elle oscille de 30 %, l’équipe sur-estime ou sous-estime, recalibrez le Planning Poker.

Étape 9 : intégrer Scrum dans les contrats clients à Dakar et Abidjan

Beaucoup de clients ouest-africains signent des cahiers des charges figés style waterfall. Pour vendre Scrum, expliquez en termes simples : forfait au sprint (par exemple 1 200 000 FCFA pour deux semaines, soit environ 1 830 EUR), livrables démontrables tous les 15 jours, possibilité d’arrêter sans pénalité après chaque sprint.

Rédigez un contrat-cadre + bons de commande par sprint. Le client garde le contrôle budgétaire, l’équipe garde sa flexibilité. Cette formule rassure les PME de Plateau et les startups du Sicap.

Découvrez aussi comment structurer votre activité freelance au Sénégal avec des contrats agiles. Comment vérifier le bon fonctionnement : trois clients sur cinq acceptent la formule au premier rendez-vous.

Étape 10 : faire évoluer Scrum vers Scrum-of-Scrums quand l’équipe grandit

Au-delà de neuf personnes, une seule équipe Scrum devient inefficace. Découpez en deux ou trois équipes de cinq, chacune avec son Scrum Master et son backlog partiel. Un Scrum-of-Scrums hebdomadaire de 30 minutes synchronise les Scrum Masters.

Cette structure fonctionne pour des projets de 15 à 50 développeurs, typique d’une scale-up à Dakar ou d’un éditeur SaaS à Abidjan. Au-delà, étudiez SAFe ou LeSS, mais ne vous y aventurez pas trop tôt.

# Format du Scrum-of-Scrums
Lundi 10h00, 30 minutes max
Chaque Scrum Master répond à 4 questions :
1. Qu'avons-nous livré la semaine passée ?
2. Que livrerons-nous cette semaine ?
3. Qu'est-ce qui bloque entre équipes ?
4. Qu'est-ce qu'une autre équipe doit savoir ?

Validation pratique : aucune équipe ne découvre un blocage transverse en cours de sprint. Si cela arrive, c’est que le Scrum-of-Scrums est mal tenu ou trop court.