Rédiger des critères d’acceptation dans Jira : exemples pratiques

« Les clients peuvent modifier leurs préférences de notification » semble un ticket clair jusqu’au début du développement. La modification s’enregistre-t-elle immédiatement ? Que se passe-t-il en cas d’échec ? La préférence sera-t-elle encore présente demain ? Quels e-mails sont concernés ?

Les critères d’acceptation transforment ces questions ouvertes en résultats convenus et observables. Ils aident les personnes qui demandent, construisent et examinent la modification à partager les mêmes attentes.

Dans ce guide, nous élaborerons des critères pour une fonctionnalité fictive de portail client, préciserons les exigences vagues et ajouterons une checklist à Definition of Done & AC de Power Pack. Aucun format particulier n’est nécessaire pour commencer. Des conditions et des résultats clairs suffisent.

Que sont les critères d’acceptation ?

Les critères d’acceptation décrivent les conditions qu’un travail particulier doit remplir pour être accepté. Ils portent sur le résultat attendu de cet élément. Atlassian les distingue de la Definition of Done, qui décrit le standard qualité plus large du travail achevé. Voir le guide d’Atlassian sur les critères d’acceptation.

Dans notre exemple, « Un choix de notification enregistré reste sélectionné après une nouvelle connexion » est un critère d’acceptation. « La réalisation a été relue » appartient à la Definition of Done commune.

Cette distinction garde les deux listes utiles. Les critères indiquent si cette fonctionnalité fait ce qui a été convenu. La Definition of Done indique si le travail respecte le standard global d’achèvement de l’équipe.

Aucune liste n’a besoin de contenir toutes les étapes de réalisation. « Créer un champ en base » peut être une tâche technique nécessaire, sans indiquer au client ni au relecteur si la préférence se comporte correctement.

Partez d’un seul résultat client

Notre ticket fictif s’appelle « Permettre aux clients de contrôler l’e-mail récapitulatif hebdomadaire ». Le résultat attendu est qu’un client connecté puisse choisir de le recevoir ou non sans modifier les messages essentiels du compte.

Avant de rédiger les critères, l’équipe convient du périmètre. Le réglage possède un bouton Save explicite. Le client ne modifie que sa propre préférence. Elle affecte les récapitulatifs qui ne sont pas encore en file d’envoi. Les messages déjà en file sont hors de la règle de livraison de ce ticket.

Ces détails sont inventés pour l’exemple. Votre équipe doit décider de son comportement réel plutôt que les copier comme exigences produit.

Une courte note de périmètre évite qu’une longue checklist doive porter tout le contexte. Dans la description Jira, l’équipe précise que le ticket concerne une préférence sur la page des paramètres du compte. Choisir les jours d’envoi, changer d’adresse e-mail et gérer les préférences d’autres clients constituent des travaux distincts.

Les critères peuvent maintenant se concentrer sur les résultats qui établissent si cette modification fonctionne.

Rédigez d’abord le parcours normal

Commencez par l’expérience attendue pour la plupart des clients. Décrivez la condition de départ, l’action et le résultat observable dans un langage ordinaire.

Par exemple : « Lorsqu’un client connecté désactive les récapitulatifs hebdomadaires et enregistre avec succès, la réouverture des paramètres montre les récapitulatifs désactivés. » Le relecteur peut créer l’état de départ, effectuer l’action et inspecter le résultat.

Cette phrase est plus utile que « Les préférences s’enregistrent correctement ». Elle précise la préférence modifiée, le moment où le changement prend effet et la façon de le vérifier.

L’équipe a aussi besoin du sens inverse. Un contrôle capable de désactiver les récapitulatifs mais incapable de les activer est incomplet. Écrivez un critère séparé lorsque le comportement inverse mérite sa propre vérification.

Ne forcez pas des résultats indépendants dans une seule entrée. Enregistrement, clavier, envoi et erreurs peuvent tous compter, mais un critère immense rend difficile de montrer ce qui nécessite encore de l’attention.

Ajoutez les erreurs et les limites

Le parcours normal suppose que l’enregistrement réussit. Demandez ce que le client doit voir lorsque cette hypothèse est fausse.

Notre équipe choisit cette règle : si la demande d’enregistrement échoue, la page affiche une erreur et aucune confirmation de succès. En la rouvrant, la préférence précédemment enregistrée est conservée. Cela fournit un cas d’échec concret à exercer dans l’environnement de test.

Examinez ensuite les limites de la fonctionnalité. Le réglage des récapitulatifs ne doit pas empêcher l’e-mail de réinitialisation du mot de passe. Le choix doit aussi survivre à une nouvelle session. Ces préoccupations étant distinctes, elles reçoivent des critères séparés.

Évitez « Tous les cas limites sont traités ». Nommez les cas importants. Une discussion utile commence souvent par trois questions : qu’est-ce qui peut échouer, qu’est-ce qui doit rester inchangé et que se passe-t-il plus tard ?

Si l’équipe ne s’accorde pas sur le résultat attendu, consignez la décision ouverte avant que la réalisation avance trop loin. Une question sans réponse ne devient pas exploitable simplement parce qu’elle figure dans une checklist.

Une checklist de critères détaillée

Voici le premier brouillon complet du ticket fictif. Chaque entrée décrit un résultat que l’équipe peut vérifier séparément.

• L’ouverture des paramètres affiche la préférence hebdomadaire actuellement enregistrée du client.
• Après désactivation des récapitulatifs et enregistrement réussi, la réouverture des paramètres affiche la préférence désactivée.
• Après activation des récapitulatifs et enregistrement réussi, la réouverture des paramètres affiche la préférence activée.
• Après un enregistrement réussi, une déconnexion puis reconnexion conserve la préférence enregistrée.
• Si l’enregistrement échoue, une erreur apparaît, aucune confirmation de succès n’est affichée et la réouverture montre la préférence précédente.
• Un client dont la préférence est désactivée ne reçoit aucun récapitulatif hebdomadaire nouvellement mis en file après l’enregistrement réussi.
• Un client dont la préférence est activée reste éligible au prochain récapitulatif selon les règles de planification existantes.
• Désactiver les récapitulatifs n’empêche pas le client de recevoir un e-mail de réinitialisation du mot de passe demandé.

Les critères d’envoi dépendent de la décision sur les messages déjà en file. L’équipe consigne ce contexte dans le ticket pour éviter que le relecteur pense que le réglage rappelle les e-mails déjà en cours d’envoi.

Ces critères nécessitent aussi une méthode de vérification réaliste. Pour l’envoi, l’équipe détermine comment déclencher ou observer un récapitulatif dans son environnement de test. Un critère clair peut rester difficile à vérifier si personne n’a accès au compte ou aux preuves d’envoi nécessaires.

Précisez les critères vagues avant de les ajouter

Une rapide revue de formulation évite souvent de longs désaccords ultérieurs. Lisez chaque entrée et demandez si deux personnes pourraient interpréter le succès différemment.

Le dernier exemple ne prouve pas à lui seul la facilité d’utilisation. Il remplace une phrase vague par un contrôle utile et limité. Des objectifs d’ergonomie plus larges peuvent exiger une étude ou plusieurs observations convenues.

Méfiez-vous aussi de la précision inventée. Ajouter une réponse en deux secondes semble mesurable, mais crée un véritable engagement. Convenez des conditions et de la raison d’un seuil de performance avant de l’inclure.

Placez les critères dans Power Pack

Ouvrez le ticket Jira et trouvez la carte Definition of Done & AC. Choisissez l’onglet Acceptance Criteria. Sa liste est distincte de Definition of Done : vérifiez l’onglet sélectionné avant de saisir le contenu.

Pour ajouter un critère, saisissez son titre puis choisissez Add ou appuyez sur Entrée. Utilisez des titres concis qui préservent le résultat attendu. Si un critère nécessite beaucoup de contexte, conservez-le dans la description Jira ou la documentation liée.

Pour plusieurs entrées, choisissez Bulk Import et collez une liste Markdown. Vous pouvez copier les exemples ci-dessus en précédant chacun d’un tiret et d’une espace. Les listes Markdown à cases à cocher sont aussi prises en charge.

Vérifiez les entrées après import. L’action ajoute à la liste actuelle : réimporter la même checklist peut créer des doublons. Les cases Markdown cochées arrivent terminées ; commencez sans coches sauf si les résultats du ticket actuel ont réellement été vérifiés.

Si une entrée est incorrecte, convenez de sa nouvelle formulation avec l’équipe, ajoutez-la puis supprimez l’ancienne à l’aide de la confirmation. Gardez la discussion du ticket claire lorsqu’un changement affecte le périmètre convenu.

Vérifiez les résultats avant de les marquer terminés

Avant la réalisation, demandez à une personne impliquée dans la vérification de parcourir les critères. Elle peut repérer des conditions initiales manquantes ou un résultat impossible à observer avec les moyens de test disponibles.

Après réalisation, vérifiez chaque résultat et consignez les preuves dans votre processus Jira ou documentaire habituel. Sélectionnez Done lorsque le résultat convenu a réussi. Une nouvelle sélection rouvre l’entrée si une découverte ultérieure remet le contrôle en question.

Par exemple, la préférence peut survivre au rechargement de la page mais se réinitialiser après une nouvelle connexion. Le critère de réouverture peut réussir alors que celui de persistance de session reste incomplet. Des entrées séparées préservent cette distinction utile.

Power Pack suit l’achèvement de la checklist ; il n’exécute pas les tests et n’établit pas automatiquement qui les a examinés. Si une vérification nominative ou datée est nécessaire, consignez explicitement ces détails dans votre processus.

Utilisez les deux compteurs sans les confondre avec des preuves

Acceptance Criteria et Definition of Done affichent chacun leurs nombres d’entrées terminées et totales. L’indicateur affiche Ready for Release seulement si les deux listes sont non vides et entièrement terminées. Sinon, il affiche In Verification.

C’est un résumé de l’état saisi. Il ne garantit ni la couverture de tous les comportements importants ni la solidité des preuves. Il n’impose pas les transitions Jira et ne bloque pas les fusions.

Notre ticket pourrait avoir huit critères d’acceptation terminés alors que les informations de support restent inachevées dans Definition of Done. Les résultats fonctionnels ont réussi, mais l’accord global d’achèvement conserve un point ouvert.

Commencez par un ticket Jira à venir. Rédigez le résultat client, convenez des conditions et résultats importants, puis ajoutez les critères dans Power Pack à côté de la Definition of Done commune. Relisez avec les personnes qui développeront et vérifieront la modification. Le bénéfice : moins d’hypothèses cachées derrière une phrase qui semblait évidente.

• Atlassian — Que sont les critères d’acceptation ?