🚦 Atelier Pratique #3

Implémenter les Limites WIP dans Jira

⏱️ Durée : 20 minutes | 🛠️ Outil : Jira

📋 Objectifs de l'Atelier

À la fin de cet atelier, vous serez capable de :

🎯 Comprendre le WIP

Qu'est-ce que le WIP ?

Work In Progress (Travail En Cours) = Le nombre de tickets actuellement en cours de réalisation dans une colonne donnée.

Pourquoi limiter le WIP ?

❌ Sans limite WIP

  • Multitâche excessif
  • Travail fragmenté
  • Délais allongés
  • Qualité réduite
  • Stress élevé

✅ Avec limite WIP

  • Focus sur moins de tâches
  • Travail terminé plus vite
  • Cycle time réduit
  • Meilleure qualité
  • Équipe plus sereine
ℹ️ Principe clé : "Stop Starting, Start Finishing" - Arrêtez de commencer de nouvelles choses, concentrez-vous sur finir ce qui est en cours !

🚀 Prérequis

📝 Étape par Étape

1 Accéder à la Configuration du Board

Navigation :

Jira → Votre Projet → Board → ... (trois points) → Configuration du Board

Vous accédez à l'interface de configuration avec plusieurs options dans le menu de gauche.

2 Accéder aux Paramètres de Colonnes
  1. Dans le menu de gauche, cliquez sur "Colonnes"
  2. Vous voyez la liste de toutes vos colonnes (To Do, In Progress, Done, etc.)
  3. Chaque colonne affiche :
    • Son nom
    • Les statuts Jira qui y sont mappés
    • L'option de limite de colonne
💡 Astuce : Si vous ne voyez pas l'option de limite WIP, vérifiez que vous avez les droits d'administration du Board.
3 Définir une Limite pour "In Progress"

Calcul de la limite WIP :

Formule simple : Nombre de personnes dans l'équipe × 1.5

Exemple pour une équipe de 4 personnes :
4 personnes × 1.5 = 6 tickets maximum en "In Progress"

Configuration :

  1. Trouvez la colonne "In Progress"
  2. Cherchez le champ "Limite de colonne" ou "Column Limit"
  3. Cochez "Définir une limite de colonne"
  4. Entrez 5 (pour cet atelier)
  5. L'option "Avertissement" s'active automatiquement
ℹ️ Types de limites :
  • Min : Nombre minimum de tickets (rarement utilisé)
  • Max : Nombre maximum de tickets (le plus courant)
4 Définir une Limite pour "In Review"

Si vous avez une colonne "In Review" (code review, testing, etc.) :

  1. Sélectionnez la colonne "In Review"
  2. Activez "Définir une limite de colonne"
  3. Entrez 3
💡 Logique : La colonne de review doit avoir une limite plus basse que "In Progress" pour éviter les goulots d'étranglement. Sinon, les tickets s'accumulent en attente de validation.

Règle générale des limites :

Colonne Limite Recommandée Raison
To Do Pas de limite C'est le backlog du Sprint
In Progress Équipe × 1.5 Travail actif
In Review Équipe × 1 ou moins Éviter les files d'attente
Testing Équipe × 1 Éviter l'accumulation
Done Pas de limite Objectif = remplir cette colonne !
5 Enregistrer et Retourner au Board
  1. En bas de la page de configuration, cliquez sur Enregistrer
  2. Retournez au Board (cliquez sur "Board" dans le menu)

Vous devriez maintenant voir les limites WIP affichées sur vos colonnes !

6 Visualiser les Limites sur le Board

Affichage des limites :

Sur chaque colonne avec une limite WIP, vous verrez :

In Progress 3/5

FORM-101 Inscription utilisateur
FORM-102 Connexion
FORM-105 Config emails

Lecture :

  • 3 = Nombre actuel de tickets dans la colonne
  • 5 = Limite maximale configurée
💡 Code couleur :
  • Vert ou Noir : Sous la limite (OK)
  • Orange : Proche de la limite (Attention)
  • Rouge : Limite dépassée (Action requise !)
7 Simuler un Dépassement de Limite

Scénario : Dépassement du WIP

Pour voir le système d'alerte en action :

  1. Déplacez plusieurs tickets vers "In Progress" jusqu'à dépasser la limite de 5
  2. Par exemple, mettez 6 ou 7 tickets en "In Progress"

Résultat visuel :

In Progress 7/5 ⚠️

FORM-101
FORM-102
FORM-103
FORM-104
FORM-105
FORM-106
FORM-107
⚠️ Alerte visuelle :
  • La colonne devient rouge ou orange
  • Un symbole d'avertissement apparaît
  • Le compteur indique le dépassement (7/5)
ℹ️ Important : Jira n'empêche PAS de dépasser la limite (c'est juste une alerte visuelle). C'est à l'équipe de respecter la discipline !
8 Appliquer la Discipline WIP

Que faire quand la limite est atteinte ?

Règle d'or :

Si "In Progress" est plein → Aidez à terminer ce qui est déjà commencé AVANT de commencer quelque chose de nouveau !

Actions concrètes :

  1. Prioriser : Identifiez le ticket le plus important en "In Progress"
  2. S'entraider : Plusieurs personnes travaillent sur le même ticket pour le finir
  3. Débloquer : Résolvez les obstacles qui empêchent l'avancement
  4. Tester/Valider : Faites avancer les tickets vers "In Review" ou "Done"
  5. Ne pas commencer : Résistez à la tentation de prendre un nouveau ticket
💡 Changement de mentalité :
  • Avant : "Je n'ai plus de travail, je prends un nouveau ticket"
  • Après : "Le WIP est plein, comment puis-je aider les autres à terminer ?"
9 Observer l'Impact sur le Flux

Exercice de comparaison :

Phase 1 - Sans WIP (historique) :

  • 10 tickets en "In Progress"
  • Chacun avance lentement
  • Rien ne se termine
  • Burndown qui stagne

Phase 2 - Avec WIP (nouveau) :

  • Maximum 5 tickets en "In Progress"
  • Focus collectif sur ces 5 tickets
  • Les tickets se terminent plus vite
  • Burndown qui descend régulièrement
ℹ️ Métriques à observer :
  • Cycle Time : Temps moyen pour terminer un ticket (devrait diminuer)
  • Throughput : Nombre de tickets terminés par jour (devrait augmenter)
  • Flow Efficiency : % de temps où le ticket progresse réellement (devrait augmenter)
10 Ajuster les Limites (Tuning)

Les limites ne sont pas figées !

Après quelques Sprints, ajustez selon les observations :

Observation Action
Colonne souvent vide Limite trop basse → Augmenter légèrement
Colonne toujours pleine et rouge Goulot d'étranglement → Investiguer la cause
Tickets qui stagnent Limite trop haute → Diminuer
Équipe frustrée de ne pas pouvoir commencer Peut-être trop restrictif → Discuter en rétro
💡 Approche empirique : Commencez avec une limite, observez pendant 2-3 Sprints, puis ajustez en rétrospective.

🎯 Exercice Pratique

Simulation de Daily Scrum avec WIP :

Imaginez ce scénario lors du Daily :

Situation :
- In Progress : 5/5 (limite atteinte)
- In Review : 3/3 (limite atteinte)
- Alice veut commencer une nouvelle Story

Question : Que devrait faire l'équipe ?

Réponse :
  1. Alice ne prend PAS de nouveau ticket
  2. L'équipe identifie ce qui bloque "In Review"
  3. Alice aide Bob à finaliser la review en cours
  4. Une fois un ticket en "Done", Alice peut en prendre un nouveau
⚠️ Anti-pattern : "Les limites WIP ne s'appliquent pas à moi car mon travail est urgent" → Non ! Les limites s'appliquent à TOUTE l'équipe sans exception.

✅ Points de Contrôle

💡 Validation réussie si :
  • Vous avez configuré au moins 2 limites WIP
  • Les limites sont visibles sur le Board
  • Vous savez interpréter les alertes visuelles
  • Vous comprenez pourquoi limiter le WIP améliore le flux
  • Vous pouvez expliquer la règle "Stop Starting, Start Finishing"
  • Vous êtes capable de décider quoi faire quand une limite est atteinte

🚀 Pour Aller Plus Loin

Concepts Avancés :

1. Limites WIP par Swimlane

Vous pouvez définir des limites différentes selon les swimlanes (par assigné, par priorité).

2. WIP Partagé

Limite globale sur plusieurs colonnes combinées (ex: "In Progress" + "In Review" = max 8).

3. Mesurer le Flow Efficiency

Flow Efficiency = Temps de travail actif / Temps total × 100%

Objectif : > 40% (sinon trop d'attente)

4. Cumulative Flow Diagram (CFD)

Graphique avancé qui montre l'évolution du WIP dans chaque colonne au fil du temps.

💡 Plugin recommandé : Pour des métriques Kanban avancées, explorez les plugins Jira comme "Actionable Metrics" ou "Advanced Roadmaps".

📊 Mesurer l'Amélioration

Métriques Avant/Après WIP :

Métrique Avant WIP Après WIP (attendu)
Cycle Time Moyen 8 jours 4-5 jours (-40%)
Tickets terminés/Sprint 12 tickets 15-18 tickets (+30%)
Tickets en cours 15-20 tickets 5-8 tickets (-60%)
Qualité (bugs) 8 bugs/Sprint 3-4 bugs/Sprint (-50%)
ℹ️ Timeline : Les bénéfices du WIP se voient généralement après 2-3 Sprints d'application disciplinée.

❓ FAQ

Q: Que faire si un ticket urgent arrive et que le WIP est plein ?

R: Trois options :

  1. Terminer rapidement un ticket en cours pour libérer de la place
  2. Retirer un ticket moins prioritaire du Sprint
  3. Accepter temporairement le dépassement MAIS en discuter immédiatement en équipe

Q: Les sous-tâches comptent-elles dans le WIP ?

R: Non, généralement seules les Stories/Tâches principales comptent. Mais c'est à définir en équipe selon votre contexte.

Q: Peut-on avoir des limites WIP différentes par personne ?

R: Non recommandé. Le WIP limite le travail de l'ÉQUIPE, pas des individus. Cela encourage la collaboration.

Q: Comment convaincre l'équipe d'adopter les limites WIP ?

R:

Q: Le Product Owner peut-il ignorer les limites WIP ?

R: Non. Les limites WIP sont une décision d'équipe pour protéger la qualité et le flux. Le PO doit les respecter.

Q: Faut-il des limites WIP sur "To Do" ?

R: Généralement non pour "To Do" dans un Sprint Scrum (c'est le Sprint Backlog). Mais pour du Kanban pur, on peut limiter le backlog pour éviter la surcharge cognitive.

🎓 Théorie : Loi de Little

La Loi de Little (1961)

Formule :

Lead Time = WIP ÷ Throughput

Traduction : Le temps pour terminer un ticket dépend du nombre de tickets en cours divisé par le débit de l'équipe.

Exemple Concret :

Scénario A - WIP élevé :

  • WIP = 20 tickets en cours
  • Throughput = 2 tickets terminés par jour
  • Lead Time = 20 ÷ 2 = 10 jours pour terminer un ticket

Scénario B - WIP limité :

  • WIP = 6 tickets en cours
  • Throughput = 2 tickets terminés par jour (même débit)
  • Lead Time = 6 ÷ 2 = 3 jours pour terminer un ticket

Résultat : En réduisant le WIP de 20 à 6, on divise le délai par 3 ! 🚀

💡 Conclusion : Pour livrer plus vite, ne commencez pas plus de choses. Terminez ce qui est commencé !

🔄 Intégration avec Scrum

WIP dans le Contexte Scrum :

Événement Scrum Utilisation du WIP
Sprint Planning Sélectionner un nombre de Stories cohérent avec les limites WIP
Daily Scrum Vérifier quotidiennement que les limites sont respectées
Sprint Review Montrer comment le WIP a aidé à tout finir
Retrospective Ajuster les limites selon les observations du Sprint
ℹ️ Scrumban : L'approche Scrumban combine les Sprints Scrum avec les limites WIP Kanban. C'est un excellent compromis pour beaucoup d'équipes !

📝 Checklist de Mise en Œuvre

Étapes pour Adopter le WIP dans Votre Équipe :

🎯 Exercice Final

Simulation de Situation Réelle :

Contexte :
Votre équipe de 5 personnes est en milieu de Sprint. État actuel du Board :
  • To Do : 8 Stories
  • In Progress : 7/5 (dépassement !)
  • In Review : 2/3
  • Done : 6 Stories

Problèmes identifiés :

  • 3 Stories en "In Progress" sont bloquées en attente de design
  • Les 2 Stories en "In Review" attendent depuis 2 jours
  • Le Product Owner demande d'ajouter une Story urgente

Questions :

  1. Quelle est la priorité immédiate ?
  2. Comment réduire le WIP de "In Progress" ?
  3. Que faire avec la nouvelle Story urgente ?
  4. Comment éviter que cette situation se reproduise ?
Proposition de Solution :
  1. Priorité : Débloquer "In Review" - 2 personnes font les reviews immédiatement
  2. Réduire WIP : Les 3 Stories bloquées sont mises en attente visible (flag 🚩), on se concentre sur les 4 autres
  3. Story urgente : On attend qu'une Story passe en "Done" avant de la commencer OU on retire une Story peu prioritaire
  4. Prévention :
    • Créer une colonne "Blocked" séparée
    • Définir une DoR incluant "les designs sont prêts"
    • Mettre une limite sur "In Review" et assigner un reviewer dédié chaque jour

🎉 Félicitations !

Vous maîtrisez maintenant les limites WIP dans Jira. Vous avez acquis une compétence clé pour optimiser le flux de travail de votre équipe !

Prochaine étape : Atelier #4 sur Confluence pour la documentation collaborative.