Maîtriser SCRUM avec Jira et Confluence
Formation Intensive - 2 Jours | Support de Cours Complet
JOUR 1 : Le Cœur de SCRUM et la Gestion du Backlog
1. Introduction au Framework SCRUM et Outils
Les Fondamentaux SCRUM
Les 3 Rôles Essentiels :
- Product Owner (PO) : Responsable de la vision produit et de la priorisation du backlog. Il représente les besoins métier et maximise la valeur créée.
- Scrum Master (SM) : Facilitateur et gardien du processus Scrum. Il élimine les obstacles et accompagne l'équipe dans l'amélioration continue.
- Équipe de Développement : Équipe auto-organisée et pluridisciplinaire (développeurs, testeurs, designers) qui transforme le backlog en incréments fonctionnels.
| Les 5 Événements SCRUM | Durée | Objectif |
|---|---|---|
| Sprint | 1-4 semaines | Itération de développement à durée fixe |
| Sprint Planning | Max 8h (Sprint 4 sem.) | Définir l'objectif et sélectionner les items à réaliser |
| Daily Scrum | 15 minutes | Synchronisation quotidienne de l'équipe |
| Sprint Review | Max 4h (Sprint 4 sem.) | Présenter l'incrément et recueillir les feedbacks |
| Sprint Retrospective | Max 3h (Sprint 4 sem.) | Identifier les améliorations de processus |
Les 3 Artefacts SCRUM :
- Product Backlog : Liste ordonnée de toutes les fonctionnalités, améliorations et corrections nécessaires au produit.
- Sprint Backlog : Sous-ensemble d'items du Product Backlog sélectionnés pour le Sprint en cours + plan de réalisation.
- Incrément : Somme de tous les items terminés durant le Sprint et des Sprints précédents, potentiellement livrable.
L'Écosystème Agile : Jira & Confluence
Jira est l'outil central pour gérer le travail quotidien. Il permet de suivre les tâches, visualiser l'avancement et mesurer la performance de l'équipe.
Confluence est l'espace de documentation et de collaboration. Il centralise les décisions, les spécifications et la connaissance de l'équipe.
Principe fondamental : Les outils supportent le processus, ils ne le dictent pas. SCRUM reste avant tout une question de mindset et de collaboration humaine.
2. Configuration et Gestion du Product Backlog
Démarrer un Projet SCRUM dans Jira
Étapes de création :
- Accéder à Jira → Projets → Créer un projet
- Sélectionner le template "Scrum"
- Nommer le projet et définir la clé (ex: FORM pour "Formation")
- Configurer les statuts de base : To Do, In Progress, Done
- Personnaliser les colonnes du tableau Scrum selon le workflow de l'équipe
Maîtriser les Types de Tickets (Issues)
| Type | Quand l'utiliser | Exemple |
|---|---|---|
| Epic | Grande fonctionnalité décomposable en plusieurs Stories | "Gestion des utilisateurs" |
| Story | Fonctionnalité du point de vue utilisateur | "En tant qu'utilisateur, je veux pouvoir me connecter afin d'accéder à mon espace personnel" |
| Tâche | Travail technique sans valeur utilisateur directe | "Configurer l'environnement de recette" |
| Bug | Anomalie ou défaut à corriger | "Le bouton de validation ne répond pas sur mobile" |
✍️ Rédiger une User Story de Qualité
Format standard :
"En tant que [rôle/persona], je veux [action/fonctionnalité] afin de [bénéfice/valeur]"
"En tant que [rôle/persona], je veux [action/fonctionnalité] afin de [bénéfice/valeur]"
Critères INVEST pour une bonne Story :
- Indépendante : Peut être réalisée sans dépendre d'autres Stories
- Négociable : Les détails peuvent être discutés avec l'équipe
- Valorisée : Apporte de la valeur à l'utilisateur final
- Estimable : L'équipe peut évaluer l'effort nécessaire
- Suffisamment petite : Réalisable en un Sprint
- Testable : On peut vérifier qu'elle fonctionne
Le Refinement et la Priorisation
Le Backlog Refinement (ou Grooming) est une activité continue où l'équipe :
- Clarifie les Stories ambiguës
- Décompose les Stories trop grandes (au-delà de 13 points)
- Estime l'effort avec des Story Points ou du temps
- Ajoute les critères d'acceptation et la Definition of Done (DoD)
Astuce Jira : Utilisez le champ "Priorité" (Highest, High, Medium, Low, Lowest) et ordonnez manuellement votre backlog par glisser-déposer pour refléter la vraie priorisation métier.
Atelier Pratique #1
Objectif : Créer un Product Backlog structuré
Consignes :
- Créer 2 Epics pour votre projet (ex: "Authentification", "Tableau de bord")
- Créer 5 User Stories liées aux Epics au format standard
- Ajouter 2 tâches techniques et 1 bug
- Prioriser les 10 éléments du plus au moins important
- Ajouter une estimation en Story Points (échelle Fibonacci: 1, 2, 3, 5, 8, 13)
Durée : 30 minutes
3. Gestion des Sprints et Tableaux Scrum
📅 La Sprint Planning
Étapes dans Jira :
- Accéder au Backlog
- Cliquer sur "Créer un Sprint"
- Définir le nom (ex: "Sprint 1 - MVP Authentification")
- Paramétrer la durée (généralement 2 semaines)
- Définir l'objectif du Sprint (Sprint Goal)
- Glisser-déposer les Stories du Backlog vers le Sprint
- Vérifier que la charge totale (Story Points) correspond à la vélocité de l'équipe
- Cliquer sur "Démarrer le Sprint"
Attention : Ne surchargez pas le Sprint ! Respectez la vélocité moyenne de l'équipe et prévoyez une marge pour les imprévus (bugs, réunions, support).
Le Scrum Board : Votre Tableau de Bord Quotidien
Le tableau Scrum visualise l'avancement en temps réel. Chaque colonne représente un statut :
- To Do : Stories sélectionnées mais pas encore commencées
- In Progress : Travail en cours de réalisation
- In Review (optionnel) : En attente de revue de code
- Testing (optionnel) : En cours de test
- Done : Terminé selon la Definition of Done
Gestion des sous-tâches : Décomposez vos Stories en sous-tâches pour un suivi plus fin. Chaque membre peut ainsi prendre une sous-tâche et la déplacer sur le tableau.
Le Daily Scrum dans Jira
Lors du Daily, chaque membre :
- Ouvre le Scrum Board
- Filtre sur ses tickets (Quick Filter "Seulement mes tickets")
- Met à jour le statut de ses tâches
- Signale les blocages avec un flag rouge
Les 3 questions du Daily :
- Qu'ai-je fait hier pour aider l'équipe à atteindre l'objectif du Sprint ?
- Que vais-je faire aujourd'hui ?
- Y a-t-il des obstacles qui m'empêchent d'avancer ?
⚙️ Personnalisation et Filtres
Ajouter une colonne personnalisée :
- Board → Paramètres du Board → Colonnes
- Ajouter une colonne (ex: "Ready for Demo")
- Mapper les statuts appropriés
Créer des Quick Filters utiles :
- Bugs uniquement :
issuetype = Bug - Haute priorité :
priority in (Highest, High) - Non assigné :
assignee is EMPTY
Atelier Pratique #2
Objectif : Simuler un Sprint
Consignes :
- Créer un Sprint de 2 semaines
- Sélectionner 3-5 Stories du backlog (max 20 Story Points)
- Démarrer le Sprint
- Créer 2-3 sous-tâches pour une Story
- Simuler l'avancement : déplacer des tickets en In Progress puis Done
- Créer un Quick Filter "Mes tickets"
Durée : 45 minutes
4. Suivi de la Performance Agile
Le Burndown Chart
Le graphique de Burndown montre l'évolution du travail restant au fil du Sprint.
- Ligne grise : Progression idéale (linéaire)
- Ligne rouge : Progression réelle de l'équipe
Interprétations :
- Ligne au-dessus de l'idéal : L'équipe est en retard, risque de ne pas tout terminer
- Ligne en dessous de l'idéal : L'équipe est en avance, bon rythme
- Ligne qui remonte : Ajout de scope en cours de Sprint (Scope Creep) - à éviter !
- Ligne plate : Aucun ticket terminé, possible blocage
La Vélocité (Velocity Chart)
La vélocité mesure la capacité moyenne de l'équipe en Story Points par Sprint.
Comment l'utiliser :
- Calculer la moyenne sur les 3-5 derniers Sprints
- Utiliser cette moyenne pour planifier les futurs Sprints
- Ne pas comparer les vélocités entre équipes (les échelles diffèrent)
- Observer les tendances : une vélocité qui baisse peut indiquer de la dette technique
Anti-pattern : Ne jamais utiliser la vélocité comme un KPI de performance individuelle ou pour comparer des équipes. C'est un outil de planification, pas de mesure de productivité.
Créer un Dashboard Jira
Étapes :
- Tableaux de bord → Créer un tableau de bord
- Ajouter des gadgets essentiels :
- Burndown Chart
- Sprint Health Gadget
- Filter Results (tickets en cours)
- Pie Chart (répartition par statut)
- Organiser la disposition
- Partager avec l'équipe
Bonne pratique : Affichez votre Dashboard sur un écran dans l'open space pour une visibilité continue de l'avancement.
JOUR 2 : Flux, Collaboration et Amélioration Continue
5. Optimisation du Flux de Travail : Scrumban
Les Principes Kanban
Kanban se concentre sur le flux continu de travail, contrairement aux itérations fixes de Scrum.
Les 4 Principes Fondamentaux :
- Visualiser le flux : Rendre visible tout le travail sur un tableau
- Limiter le WIP (Work In Progress) : Réduire le travail en cours pour augmenter l'efficacité
- Gérer le flux : Optimiser la fluidité du passage d'une étape à l'autre
- Améliorer continuellement : Utiliser les métriques pour identifier les goulots d'étranglement
Limiter le WIP
Pourquoi limiter le travail en cours ?
- Réduire le temps de cycle (Lead Time)
- Augmenter la concentration de l'équipe
- Identifier rapidement les blocages
- Améliorer la qualité (moins de multitâche)
- Finir plus vite ce qui est commencé
Règle pratique : Limiter le WIP à 1-2 tickets par personne en "In Progress". Si quelqu'un est bloqué, il aide les autres plutôt que de commencer quelque chose de nouveau.
Configuration dans Jira :
- Board → Configuration → Colonnes
- Définir une limite max pour chaque colonne
- Jira affichera un avertissement visuel si la limite est dépassée
Mesurer le Flux
| Métrique | Définition | Objectif |
|---|---|---|
| Lead Time | Temps entre la création du ticket et sa mise en production | Mesurer le délai total de bout en bout |
| Cycle Time | Temps entre le début du travail et sa finalisation | Mesurer l'efficacité de réalisation |
| Throughput | Nombre de tickets terminés par période | Mesurer le débit de l'équipe |
Le Scrumban : Le Meilleur des Deux Mondes
Scrumban combine la structure des Sprints Scrum avec la flexibilité du flux Kanban.
Quand utiliser Scrumban ?
- Équipes de maintenance avec beaucoup d'imprévus
- Support technique avec des demandes continues
- Projets nécessitant à la fois planification et réactivité
- Transition progressive de Scrum vers Kanban
Caractéristiques :
- Sprints de durée fixe (Scrum)
- Limites WIP sur le tableau (Kanban)
- Priorités continues dans le backlog (Kanban)
- Rétrospectives régulières (Scrum)
Atelier Pratique #3
Objectif : Implémenter des limites WIP
Consignes :
- Accéder aux paramètres de colonnes de votre Board
- Définir une limite WIP pour "In Progress" (ex: 5)
- Définir une limite pour "In Review" (ex: 3)
- Observer visuellement la charge sur le tableau
- Simuler un dépassement de limite
Durée : 20 minutes
6. Confluence pour la Collaboration et la Documentation
📖 Structurer l'Espace Confluence
Architecture recommandée :
- Page d'accueil : Vue d'ensemble du projet, liens rapides, équipe
- Documentation Produit
- Vision et roadmap
- Personas utilisateurs
- Architecture technique
- Processus Agile
- Definition of Done (DoD)
- Definition of Ready (DoR)
- Workflow et conventions
- Sprints
- Rétrospectives
- Notes de Review
- Décisions importantes
- Connaissances
- FAQ technique
- Guides et tutoriels
- Incidents post-mortem
Créer la Definition of Done (DoD)
Exemple de Definition of Done :
- Le code est écrit et respecte les conventions de l'équipe
- Les tests unitaires sont écrits et passent (couverture > 80%)
- La revue de code est approuvée par au moins 1 pair
- Les tests d'intégration passent
- La documentation technique est mise à jour
- La Story est testée en environnement de recette
- Le Product Owner a validé la fonctionnalité
- Le code est mergé sur la branche principale
Principe : Une Story n'est "Done" que si TOUS les critères de la DoD sont remplis. Pas de "presque fini" !
Créer la Definition of Ready (DoR)
Exemple de Definition of Ready :
- La User Story est rédigée au format standard
- Les critères d'acceptation sont clairs et testables
- La Story est estimée par l'équipe
- Les dépendances sont identifiées et documentées
- Les maquettes/wireframes sont disponibles si nécessaire
- L'équipe comprend la valeur métier
- La Story est suffisamment petite (< 13 points)
Utiliser les Templates Confluence
Template de Rétrospective :
- Créer une nouvelle page → Choisir "Retrospective"
- Sections automatiques :
- Ce qui a bien marché
- Ce qui peut être amélioré
- Idées d'amélioration
- Actions à mettre en place
Autres templates utiles :
- Product Requirements : Pour les spécifications détaillées
- Meeting Notes : Pour les comptes-rendus de réunions
- Decision : Pour documenter les décisions architecturales importantes
- How-to Article : Pour les guides et tutoriels
Intégration Jira-Confluence
Lier une page Confluence à un Epic Jira :
- Ouvrir l'Epic dans Jira
- Cliquer sur "..." → "Confluence Pages"
- Créer une nouvelle page ou lier une page existante
- La page apparaîtra directement dans l'Epic
Afficher des tickets Jira dans Confluence :
- Éditer une page Confluence
- Taper "/" puis "Jira"
- Sélectionner "Jira Issues"
- Configurer le filtre JQL (ex:
project = FORM AND sprint = "Sprint 1") - Choisir le format d'affichage (tableau, liste, graphique)
Cas d'usage : Créez une page "Sprint Overview" qui affiche automatiquement tous les tickets du Sprint en cours avec leur statut. Parfait pour les présentations !
Atelier Pratique #4
Objectif : Créer un espace de documentation complet
Consignes :
- Créer un espace Confluence pour votre projet
- Créer une page "Definition of Done" avec 5-7 critères
- Créer une page "Definition of Ready" avec 5-7 critères
- Créer une page avec le macro "Jira Issues" affichant les tickets du Sprint en cours
- Lier cette page à un Epic dans Jira
Durée : 45 minutes
7. Clôture et Amélioration Continue
La Sprint Review
Objectif : Présenter l'incrément fonctionnel réalisé pendant le Sprint et recueillir les feedbacks des parties prenantes.
Déroulement recommandé :
- Rappel de l'objectif du Sprint (5 min)
- Le Product Owner rappelle le Sprint Goal
- Présentation de l'incrément (30-45 min)
- Démonstration live des fonctionnalités "Done"
- L'équipe de développement présente son travail
- Focus sur la valeur apportée, pas sur le code
- Discussion et feedback (15-30 min)
- Questions des parties prenantes
- Validation ou ajustements nécessaires
- Revue du Product Backlog (15 min)
- Mise à jour des priorités selon les retours
- Projection sur les prochains Sprints
Erreur fréquente : Ne présentez QUE ce qui est "Done" selon votre DoD. Pas de "c'est presque fini" ou "il reste juste un bug". Si ce n'est pas Done, ce n'est pas présenté.
Dans Jira :
- Filtrer le Board sur "Done"
- Utiliser le Report → "Sprint Report" pour visualiser ce qui a été accompli
- Documenter les retours importants dans Confluence
La Sprint Retrospective
Objectif : Identifier ce qui peut être amélioré dans la façon de travailler de l'équipe.
Format classique (Start-Stop-Continue) :
- Start : Quelles nouvelles pratiques devons-nous adopter ?
- Stop : Qu'est-ce qui ne fonctionne pas et doit être arrêté ?
- Continue : Qu'est-ce qui fonctionne bien et doit être maintenu ?
Autres formats de rétrospective :
- Sailboat : Vent (ce qui nous pousse), Ancre (ce qui nous retient), Rochers (risques)
- 4L : Liked, Learned, Lacked, Longed for
- Mad-Sad-Glad : Ce qui nous a mis en colère, attristé, ou réjoui
Règles d'or de la rétrospective :
- Safe space : Ce qui est dit en rétro reste en rétro
- Pas de jugement : On critique les processus, pas les personnes
- Actions concrètes : Toute discussion doit mener à des actions
- Suivi : Les actions deviennent des tickets Jira assignés
- Time-boxed : Respecter le temps imparti
Workflow dans Confluence + Jira :
- Créer une page Rétrospective dans Confluence (template)
- Documenter les points soulevés par l'équipe
- Voter sur les actions prioritaires (plugin Confluence Poll)
- Créer un ticket Jira de type "Tâche" pour chaque action retenue
- Assigner et mettre dans le Sprint suivant
- Lors de la prochaine rétro, vérifier que les actions ont été réalisées
Astuce : Créez un label "retro-action" dans Jira pour suivre facilement toutes vos actions d'amélioration continue.
Clôture du Sprint dans Jira
Procédure :
- Accéder au Board → Rapports → Sprint Report
- Vérifier les tickets Done et ceux non terminés
- Backlog → Cliquer sur "Terminer le Sprint"
- Jira propose de déplacer les tickets non terminés :
- Vers le Backlog : Si la Story n'est plus prioritaire
- Vers le prochain Sprint : Si elle reste prioritaire
- Confirmer la clôture
Attention au report systématique : Si une Story est reportée plus de 2 fois, c'est un signal d'alerte. Elle est peut-être trop grosse, mal comprise, ou bloquée. Prenez le temps de l'analyser en équipe.
Analyser la Vélocité
Après la clôture du Sprint :
- Accéder au Velocity Chart
- Observer les tendances sur les 3-5 derniers Sprints
- Calculer la vélocité moyenne
- Utiliser cette donnée pour la planification du prochain Sprint
Interprétation :
- Vélocité stable : Équipe mature, prédictibilité élevée
- Vélocité en hausse : Amélioration des pratiques, montée en compétence
- Vélocité en baisse : Dette technique, démotivation, ou changement d'équipe
- Vélocité erratique : Estimation imprécise ou Sprints perturbés
8. Atelier Synthèse Pratique
Simulation Complète d'un Mini-Sprint
Objectif : Appliquer l'ensemble du cycle SCRUM de bout en bout
Mise en situation :
Vous êtes une équipe qui développe une application de gestion de tâches. Vous allez réaliser un Sprint complet de 30 minutes (au lieu de 2 semaines).
Étapes à réaliser :
1. Sprint Planning (5 min)
- Créer un Sprint "Mini-Sprint Formation"
- Définir l'objectif : "Permettre à l'utilisateur de créer et visualiser des tâches"
- Sélectionner 2-3 Stories du backlog
- Estimer en Story Points
- Démarrer le Sprint
2. Travail et Daily Scrum (15 min)
- Créer des sous-tâches pour vos Stories
- Déplacer les tickets sur le Board (To Do → In Progress → Done)
- Simuler un Daily : chaque membre explique son avancement
- Créer 1 bug découvert "en cours de Sprint"
- Observer le Burndown Chart en temps réel
3. Documentation Confluence (5 min)
- Créer une page de spécification pour une Story
- La lier à l'Epic correspondant dans Jira
- Ajouter une capture d'écran du Board
4. Sprint Review (3 min)
- Un membre présente les Stories "Done" à l'équipe
- Consulter le Sprint Report dans Jira
5. Retrospective (5 min)
- Créer une page Rétrospective dans Confluence
- Noter 2-3 points positifs et 2-3 axes d'amélioration
- Créer 1 action d'amélioration comme ticket Jira
6. Clôture (2 min)
- Terminer le Sprint dans Jira
- Observer la vélocité obtenue
Récapitulatif et Bonnes Pratiques
Checklist du Scrummer Efficace
Avant le Sprint :
- Le Product Backlog est priorisé et raffiné
- Les Stories sont Ready (respectent la DoR)
- L'équipe connaît sa vélocité moyenne
- La DoD est claire et partagée
- Le Sprint Goal est visible et compris de tous
- Le Board est mis à jour quotidiennement
- Les blocages sont signalés immédiatement
- Le WIP est limité et respecté
- La documentation technique est faite au fur et à mesure
- Seules les Stories Done sont présentées en Review
- La rétrospective génère des actions concrètes
- Les tickets non terminés sont analysés avant d'être reportés
- Les apprentissages sont documentés dans Confluence
Les Anti-Patterns à Éviter
- Le Sprint à rallonge : Ne jamais étendre un Sprint. Si le travail n'est pas fini, il est reporté.
- L'ajout de scope en cours de Sprint : Le Sprint Backlog est figé après la Planning.
- Le Daily interminable : Maximum 15 minutes. Les discussions détaillées se font après.
- La DoD négociable : "Done" signifie Done. Pas de compromis.
- La rétrospective sans actions : Si rien ne change, c'est du temps perdu.
- Les estimations comme engagements : Les Story Points ne sont PAS des promesses.
- Ignorer les métriques : Si vous ne regardez jamais le Burndown, pourquoi le générer ?
Les Principes d'Or
- La transparence avant tout : Tout est visible, rien n'est caché sous le tapis.
- L'inspection régulière : On vérifie constamment qu'on va dans la bonne direction.
- L'adaptation continue : On ajuste dès qu'on détecte un problème.
- Le respect mutuel : On fait confiance à l'équipe auto-organisée.
- La focalisation sur la valeur : Chaque action doit créer de la valeur pour l'utilisateur final.
- Le courage de dire non : Savoir refuser ce qui n'apporte pas de valeur ou compromet la qualité.
📖 Ressources Complémentaires
Documentation officielle :
- The Scrum Guide : scrumguides.org
- Jira Documentation : support.atlassian.com/jira
- Confluence Documentation : support.atlassian.com/confluence
Pour aller plus loin :
- Livres recommandés :
- "SCRUM : Le guide pratique de la méthode agile la plus populaire" - Claude Aubry
- "User Story Mapping" - Jeff Patton
- "The Lean Startup" - Eric Ries
- Certifications :
- PSM I (Professional Scrum Master)
- PSPO (Professional Scrum Product Owner)
- Atlassian Jira Administrator
Conclusion
Félicitations ! Vous avez maintenant toutes les connaissances nécessaires pour mettre en œuvre SCRUM avec Jira et Confluence de manière efficace.
Les clés du succès :
- Commencez simple : N'implémentez pas toutes les fonctionnalités d'un coup. Maîtrisez les bases avant d'optimiser.
- Itérez sur votre processus : SCRUM s'applique aussi à la manière dont vous faites du SCRUM. Améliorez continuellement.
- Impliquez toute l'équipe : Les outils ne font pas l'agilité, c'est la collaboration humaine qui prime.
- Utilisez les données : Les métriques sont là pour vous guider, pas pour juger.
- Communiquez sans cesse : La sur-communication n'existe pas en agilité.
Prochaines étapes :
- Appliquez immédiatement ce que vous avez appris dans votre contexte réel
- Organisez une rétrospective après votre premier Sprint pour ajuster
- Partagez vos apprentissages avec votre équipe
- N'hésitez pas à expérimenter et à adapter SCRUM à votre réalité
Dernier conseil : SCRUM est un framework, pas une religion. Adaptez-le à votre contexte tout en respectant ses valeurs fondamentales : engagement, courage, focus, ouverture et respect.