Critères d'acceptation

Les critères d'acceptation définissent les conditions qui doivent être remplies pour qu'une user story soit considérée comme terminée. Ils transforment des exigences vagues en spécifications testables, éliminant l'ambiguïté et empêchant la dérive du périmètre.

Objectif

Les critères d'acceptation servent plusieurs rôles :

Pour les développeurs : Exigences claires avant de commencer à coder Pour les testeurs : Conditions exactes à vérifier Pour les parties prenantes : Définition transparente des livrables Pour les product owners : Application des limites du périmètre

Sans critères d'acceptation, "terminé" devient subjectif. Avec eux, la complétion est binaire—tous les critères passent ou le travail continue.

Accéder à l'éditeur

Ouvrez les critères d'acceptation depuis les détails de la user story :

1. Naviguez vers n'importe quelle user story
2. Cliquez sur l'onglet Détails
3. Trouvez la section Critères d'acceptation
4. Cliquez sur le bouton Modifier (icône crayon)

L'éditeur s'ouvre dans une fenêtre modale avec des options de formatage de texte enrichi.

Fonctionnalités de l'éditeur

Barre d'outils de formatage

L'éditeur de critères d'acceptation supporte :

Support du texte enrichi

L'éditeur préserve le formatage lors du collage depuis :

• Google Docs
• Confluence
• Notion
• Microsoft Word

Collez le contenu formaté directement—la structure se transfère automatiquement.

Rédiger des critères efficaces

Le format Given-When-Then

Cette structure crée des conditions non ambiguës et testables :

Étant donné [précondition]
Quand [action]
Alors [résultat attendu]

Exemple :

Étant donné que je suis connecté en tant qu'administrateur
Quand je clique sur "Supprimer l'utilisateur" et confirme le dialogue
Alors l'utilisateur est supprimé du système
Et je vois une notification de succès
Et l'utilisateur n'apparaît plus dans la liste des utilisateurs

Format checklist

Pour des validations plus simples, utilisez des cases à cocher :

- [ ] Le formulaire valide le format email
- [ ] Le mot de passe requiert 8+ caractères
- [ ] Le bouton soumettre est désactivé jusqu'à ce que le formulaire soit valide
- [ ] Les messages d'erreur s'affichent sous les champs invalides
- [ ] Le succès redirige vers le tableau de bord

Spécification par l'exemple

Montrez le comportement attendu exact :

Entrée : "jean@exemple.com"
Attendu : Valide, passer à l'étape suivante

Entrée : "jean@"
Attendu : Erreur "Format email invalide"

Entrée : ""
Attendu : Erreur "L'email est requis"

Catégories de critères

Critères fonctionnels

Ce que la fonctionnalité doit faire :

Étant donné un utilisateur avec des articles dans le panier
Quand il clique sur "Commander"
Alors il voit le formulaire de paiement
Et le total du panier s'affiche correctement
Et les options de livraison sont calculées

Critères non-fonctionnels

Comment la fonctionnalité doit performer :

Performance :
- La page charge en moins de 2 secondes
- La recherche retourne les résultats en moins de 500ms
- Supporte 100 utilisateurs simultanés

Accessibilité :
- Tous les champs de formulaire ont des labels
- La navigation par tabulation fonctionne correctement
- Compatible avec les lecteurs d'écran

Cas limites

Conditions aux limites et états d'erreur :

Cas limites gérés :
- Une recherche vide retourne un message utile
- Un timeout réseau affiche l'option de réessayer
- L'expiration de session redirige vers la connexion
- Les données invalides affichent des erreurs spécifiques

Critères de sécurité

Exigences de protection :

Exigences de sécurité :
- Les mots de passe sont hashés avant stockage
- La session expire après 30 min d'inactivité
- Les tentatives de connexion échouées limitées à 5
- Les données sensibles ne sont pas loguées

Anti-patterns à éviter

Trop vague

❌ Mauvais :

- Devrait fonctionner correctement
- Doit être rapide
- Doit gérer les erreurs

✅ Bon :

- Retourne un statut 200 sur entrée valide
- Répond en moins de 500ms en charge normale
- Affiche "Erreur réseau, veuillez réessayer" sur timeout

Trop technique

❌ Mauvais (sauf si l'équipe est entièrement développeurs) :

- Utilise Redis pub/sub pour les mises à jour temps réel
- Implémente le verrouillage optimiste avec ETag
- Déploie via Kubernetes rolling update

✅ Bon :

- Les changements apparaissent pour tous les utilisateurs en 3 secondes
- Les modifications simultanées affichent un avertissement de conflit
- Le déploiement ne cause aucune interruption de service

Tester l'implémentation

❌ Mauvais :

- Utilise correctement les hooks React
- Les requêtes base de données sont optimisées
- Le code suit le guide de style

✅ Bon :

- Le composant ne se re-rend que quand les données changent
- La liste charge en moins de 1 seconde pour 10 000 éléments
- Cohérent avec les patterns UI existants

Dérive du périmètre

❌ Mauvais (ajoute du travail hors story) :

- Ajouter aussi le support du mode sombre
- Inclure l'export en PDF
- Ajouter les raccourcis clavier

✅ Bon (rester dans le périmètre de la story) :

- Le tableau de bord affiche tous les widgets
- Les widgets chargent la configuration sauvegardée de l'utilisateur
- La mise en page persiste entre les sessions

Intégration au workflow

Pendant la planification

1. Création de story : Rédiger les critères initiaux
2. Affinage : L'équipe discute, ajoute les cas limites
3. Estimation : Les critères informent l'attribution des story points
4. Planification de sprint : Les critères vérifient que la story est prête

Pendant le développement

1. Référence : Le développeur vérifie les critères en codant
2. Auto-test : Le développeur vérifie chaque critère avant la PR
3. Revue de code : Le reviewer vérifie la couverture des critères

Pendant les tests

1. Création de cas de test : Chaque critère devient un cas de test
2. Vérification : Le testeur valide tous les critères
3. Rapports de bug : Référence les critères spécifiques qui échouent

Pendant la démo

1. Démonstration : Montrer chaque critère satisfait
2. Validation : La partie prenante confirme l'acceptation

Raccourcis clavier

Dans l'éditeur de critères d'acceptation :

Bonnes pratiques

1. Rédiger les critères avant le développement

Les critères rédigés après le code ont tendance à correspondre à l'implémentation plutôt qu'aux exigences. Rédigez d'abord, codez ensuite.

2. Impliquer l'équipe

Les développeurs repèrent les lacunes techniques. Les testeurs trouvent les cas limites. Incluez les deux perspectives lors de la rédaction.

3. Garder les critères atomiques

Chaque critère teste une seule chose :

❌ Combiné :

L'utilisateur peut se connecter avec les bons identifiants et voit le tableau de bord avec ses données

✅ Atomique :

- Les identifiants valides accordent l'accès
- Les identifiants invalides affichent une erreur
- Le tableau de bord s'affiche après la connexion
- Le tableau de bord montre uniquement les données de l'utilisateur

4. Utiliser un langage cohérent

Établissez des conventions d'équipe :

• "Utilisateur" vs "Client" vs "Membre"
• "Cliquer" vs "Sélectionner" vs "Choisir"
• "Afficher" vs "Montrer" vs "Rendre"

5. Inclure les cas négatifs

Ce qui ne doit PAS arriver compte aussi :

- Le mot de passe n'est jamais affiché dans les logs
- Les données supprimées ne peuvent pas être récupérées
- Une session expirée ne peut pas accéder aux routes protégées

6. Versionner les critères

Quand les exigences changent, mettez à jour les critères et notez pourquoi :

Mis à jour 2024-01-15 : Ajout exigence 2FA suite à l'audit sécurité
Précédent : La connexion requiert email + mot de passe
Actuel : La connexion requiert email + mot de passe + code 2FA

Templates courants

Opérations CRUD

Créer :
- Une entrée valide crée l'enregistrement
- Une entrée invalide affiche des erreurs spécifiques
- La prévention des doublons fonctionne

Lire :
- Les utilisateurs autorisés voient les données
- Les utilisateurs non autorisés voient une erreur
- L'état vide affiche un message utile

Mettre à jour :
- Les modifications se sauvegardent correctement
- La validation s'applique aux mises à jour
- La gestion des modifications simultanées fonctionne

Supprimer :
- Confirmation requise
- La suppression douce préserve les données
- La suppression définitive supprime complètement

Validation de formulaire

Champ : Email
- Requis (affiche erreur si vide)
- Validation du format (utilisateur@domaine.com)
- Longueur max : 254 caractères
- Vérification unicité (affiche erreur si existe)

Champ : Mot de passe
- Requis
- Minimum 8 caractères
- Au moins un chiffre
- Au moins un caractère spécial
- L'indicateur de force s'affiche

Endpoint API

Endpoint : GET /api/users/{id}

Succès (200) :
- Retourne l'objet utilisateur
- Exclut les champs sensibles (mot de passe, tokens)
- Temps de réponse < 200ms

Non trouvé (404) :
- Retourne le format d'erreur standard
- Message : "Utilisateur non trouvé"

Non autorisé (401) :
- Token manquant retourne erreur
- Token expiré retourne erreur
- Token invalide retourne erreur

Dépannage

Le formatage ne se sauvegarde pas :

• Vérifiez la console du navigateur pour les erreurs
• Essayez de vider le cache du navigateur
• Assurez-vous d'avoir une connexion réseau stable

L'éditeur ne s'ouvre pas :

• Vérifiez la permission edituserstories
• Vérifiez que la story n'est pas archivée
• Rafraîchissez la page et réessayez

Le contenu collé perd son format :

• Essayez Coller et adapter le style (Cmd/Ctrl + Shift + V)
• Utilisez le format Markdown pour le contenu complexe
• Divisez en opérations de collage plus petites

Les modifications ne sont pas visibles par l'équipe :

• Vérifiez que la sauvegarde est terminée (modal fermée)
• Vérifiez les erreurs de synchronisation dans le flux d'activité
• Les membres de l'équipe peuvent avoir besoin de rafraîchir

Créer une user story

Les user stories capturent les exigences du point de vue de l'utilisateur final. Chaque story suit le format : "En tant que [qui], je veux [quoi], afin de [pourquoi]." Cette structure garantit que chaque fonctionnalité a un objectif clair et une valeur mesurable.

Ouvrir la modale

Accédez à la modale de création par plusieurs chemins :

• En-tête du projet : Cliquez sur le bouton "Nouveau" dans la section user stories
• Raccourci clavier : Cmd/Ctrl + Shift + U depuis n'importe où dans le projet
• État vide : Cliquez sur le lien "Créer votre première user story"
• Création rapide : Utilisez le menu de création rapide global et sélectionnez "User Story"

La modale s'ouvre avec votre projet actuel pré-sélectionné. Si vous avez ouvert depuis le menu global, sélectionnez d'abord l'espace de travail et le projet.

Modes de création

Mode traditionnel

Rédigez les user stories dans le format standard :

Structure du template :

En tant que [type d'utilisateur],
Je veux [un objectif],
Afin de [une raison].

Exemple :

En tant que chef de projet,
Je veux voir les graphiques de burndown de sprint,
Afin de suivre la vélocité de l'équipe.

Le format traditionnel garantit :

• Identification claire du persona utilisateur
• Énoncé d'objectif spécifique et actionnable
• Justification de la valeur métier

Rédiger des stories efficaces :

1. Soyez spécifique sur l'utilisateur. "En tant qu'utilisateur" est trop vague. Utilisez "En tant qu'administrateur de facturation" ou "En tant que visiteur première fois"

1. Concentrez-vous sur un objectif. Si vous écrivez "et" dans la clause vouloir, envisagez de diviser en plusieurs stories

1. Énoncez une valeur mesurable. "Afin de gagner du temps" est faible. "Afin de traiter 50% de factures en plus" est actionnable

Mode IA

Décrivez ce dont vous avez besoin en langage naturel. L'IA génère une user story correctement formatée :

Entrée :

Besoin d'un moyen pour les managers d'approuver les entrées de temps avant qu'elles n'aillent à la facturation

Story générée :

En tant que manager d'équipe,
Je veux réviser et approuver les entrées de temps avant export,
Afin que la précision de la facturation s'améliore et les litiges diminuent.

Le mode IA excelle quand :

• Vous convertissez des demandes parties prenantes en format user story
• Vous transformez des rapports de bug en stories d'amélioration
• Vous décomposez des exigences vagues en besoins spécifiques

Champs de la modale

Titre (Requis)

En mode Traditionnel, c'est votre texte complet de user story. En mode IA, c'est votre description en langage naturel.

Limite de caractères : 500 caractères Bonne pratique : Gardez les titres scannables. La première ligne doit résumer la story.

Critères d'acceptation

Définissez ce que "terminé" signifie pour cette story. Utilisez des conditions testables :

Critères faibles :

- Devrait fonctionner correctement
- Doit être rapide
- Doit bien paraître

Critères forts :

- Les entrées de temps s'affichent par ordre chronologique
- Le manager peut approuver/rejeter les entrées individuelles
- Les entrées rejetées retournent au soumetteur avec commentaire obligatoire
- Les entrées approuvées marquées avec horodatage et nom de l'approbateur
- La page charge en moins de 2 secondes pour jusqu'à 500 entrées

Options de format :

Given/When/Then :

Étant donné que je suis un manager connecté
Quand je consulte les entrées de temps en attente
Alors je vois les entrées groupées par membre d'équipe

Style checklist :

- [ ] Le filtre par plage de dates fonctionne
- [ ] L'approbation en masse des entrées sélectionnées fonctionne
- [ ] L'export des entrées approuvées en CSV fonctionne

Informations supplémentaires

Contexte qui aide pendant l'implémentation :

• Liens vers les maquettes de design
• Contraintes techniques
• Documentation connexe
• Contacts parties prenantes
• Cas limites à considérer

Ce champ supporte le formatage Markdown complet incluant liens, blocs de code et images.

Priorité

Définissez le niveau d'urgence depuis la liste de priorités de votre projet :

La priorité affecte :

• Le tri par défaut dans les vues de backlog
• Les suggestions de planification de sprint
• Les calculs de charge de travail de l'équipe

Epic

Liez la story à un epic parent pour l'organisation :

Aucun Epic sélectionné : La story apparaît dans le backlog sans groupement Epic sélectionné : La story se groupe sous l'epic dans les vues roadmap et planification

Créer un Epic en ligne : Cliquez sur "Créer nouvel epic" pour ajouter un epic sans quitter la modale. Entrez le titre et sauvegardez—le nouvel epic est immédiatement sélectionnable.

Ceci est précieux quand :

• Une story révèle le besoin d'une nouvelle initiative
• Une partie prenante demande une fonctionnalité hors des epics existants
• Vous décomposez une grande exigence en epic + stories

Validation du formulaire

Le bouton créer s'active quand :

1. Projet sélectionné : Requis pour toutes les stories
2. Titre fourni : Minimum 3 caractères
3. Contenu approprié au mode : Soit format traditionnel soit description IA

Les erreurs de validation apparaissent en ligne :

• Titre vide : "Le titre est requis"
• Titre trop court : "Minimum 3 caractères"
• Pas de projet : "Sélectionnez d'abord un projet"

Après la création

État de succès

La modale confirme la création avec des options :

Aller aux User Stories : Navigue vers le board des user stories du projet En créer une autre : Vide le formulaire, reste dans la modale pour création en lot

Ce qui se passe

1. Story créée avec statut "Ouverte"
2. Apparaît dans le backlog prête pour la planification de sprint
3. Liée à l'epic si sélectionné
4. Équipe notifiée via le flux d'activité du projet
5. Synchronisation temps réel sur toutes les vues des membres de l'équipe

Raccourcis clavier

Bonnes pratiques

Rédiger de façon indépendante

Chaque story doit être complétable sans dépendances :

Dépendante (éviter) :

En tant qu'utilisateur, je veux voir le tableau de bord créé dans US-123

Indépendante (préféré) :

En tant qu'utilisateur, je veux voir les métriques clés sur mon tableau de bord

Dimensionner correctement

Les stories doivent se terminer dans un sprint. Si plus grandes :

• Divisez en plusieurs stories
• Utilisez un epic pour grouper les stories liées
• Envisagez le pattern "En tant qu'utilisateur, je veux [partie 1]"

Inclure les critères d'acceptation

Chaque story a besoin de conditions testables. Ce n'est pas optionnel—c'est ainsi que votre équipe sait quand le travail est terminé.

Investissement en temps : 5 minutes à rédiger les critères économisent 2 heures de questions de clarification plus tard.

Connecter aux epics

Les stories orphelines créent le chaos de planification. Même les "améliorations diverses" méritent un epic pour le groupement.

Patterns courants

Story fonctionnalité

En tant que [type d'utilisateur],
Je veux [capacité],
Afin de [valeur métier].

Conversion bug-en-story

En tant que [utilisateur affecté],
Je veux que [chose cassée] soit réparée,
Afin de [impact une fois réparé].

Story technique

En tant que développeur,
Je veux [amélioration technique],
Afin de [bénéfice maintenance/performance].

Story de recherche

En tant que chef de produit,
Je veux comprendre [inconnu],
Afin de [décisions futures].

Dépannage

La modale ne s'ouvre pas :

• Vérifiez les permissions du projet (besoin de createuserstories)
• Assurez-vous qu'un projet est sélectionné dans la navigation
• Essayez un rafraîchissement de page

Le mode IA ne génère pas :

• Fournissez plus de détails dans la description
• Incluez le contexte sur le type d'utilisateur et l'objectif
• Vérifiez la connexion réseau

Impossible de sélectionner un epic :

• Les epics se chargent après la sélection du projet
• Créez un nouvel epic si aucun n'existe
• Vérifiez que l'epic n'est pas archivé

Menu déroulant de priorité vide :

• Les priorités viennent des paramètres du projet
• L'admin peut ajouter des priorités dans Paramètres projet → Priorités