Une checklist de critères d’acceptation qui reste sur l’élément de travail

Critères d’acceptation, Definition of Done et Definition of Ready

Definition of Done est identique sur chaque story : tests, revue, documentation. Les critères d’acceptation, eux, changent avec le travail — « le propriétaire du compte peut exporter un CSV en moins de cinq secondes ». Definition of Ready demande si ces exemples existent avant de commencer. La checklist de tests QA permet de les vérifier. Utiliser les trois comme checklists sur l’élément de travail apporte de la clarté et réduit l’ambiguïté : l’avancement et les prochaines étapes se voient sans chasse au trésor.

Un exemple : une API qui liste des tickets Jira

Les critères d’acceptation diffèrent généralement d’une story à l’autre : chaque liste décrit ce que cet élément de travail doit livrer. Imaginez un élément de backlog que votre équipe pourrait vraiment prendre : construire un endpoint GET qui renvoie la liste paginée des tickets Jira d’un projet. L’équipe produit veut des champs et des permissions clairs. L’équipe de développement veut la pagination et le format des erreurs validés. L’équipe QA veut un endpoint qu’elle puisse appeler avec curl pour une démo rapide.

La checklist ci-dessous, c’est ce que cette story porterait sur l’élément de travail : pas un modèle valable pour toutes les API, mais un schéma — qui peut l’appeler, à quoi ressemble le succès, à quoi ressemble l’échec, et comment vous montreriez que ça fonctionne.

Le meilleur test pour chaque ligne : quelqu’un peut-il la démontrer sans deviner ? La story suivante aura sa propre liste — même principe, autres exemples.

Cette liste n’appartient qu’à cette story. Dans Checklist for Jira, vous ajoutez ce genre d’éléments directement sur l’élément de travail, vous les cochez à mesure que le comportement est implémenté, et vous enregistrez un court modèle de départ quand la forme des stories de votre équipe se répète — avec de nouveaux exemples écrits à chaque fois.

Enregistrez une trame, adaptez-la story par story

1. Checklist for Jira ajoute un panneau de checklist dans la vue du ticket. Ajoutez-y les critères d’acceptation de votre scénario : servez-vous de l’exemple ci-dessus comme schéma et remplissez les lignes propres à votre travail.
2. Si vous voulez une trame réutilisable, enregistrez les intitulés (périmètre, cas nominal, erreurs, prêt pour la démo) comme modèle de projet ou global, puis réécrivez chaque ligne au démarrage de la story suivante.
3. Vous pouvez configurer l’automatisation modèle par modèle pour ajouter cette trame à la création d’une Story ou au passage en In Progress — ou l’appliquer à la main depuis Add → Add from template quand vous en avez besoin.
4. Si votre équipe veut des points de contrôle stricts dans son processus, ajoutez un validateur de complétion sur une transition de workflow.
5. Réinitialisez ou mettez à jour les éléments quand le périmètre bouge ; combinez avec Definition of Done à la fin et la checklist de tests QA quand les testeurs mènent une passe dédiée — voir le guide d’automatisation.

Combinez-la avec le reste du kit de livraison

Gardez Definition of Done sur le même ticket pour le seuil de livraison. Attachez la checklist de tests QA quand quelqu’un a besoin d’une passe de tests structurée. Utilisez Definition of Ready pendant l’affinage si la qualité d’entrée aide votre équipe. Parcourez le catalogue de modèles pour la collection complète.

Questions fréquentes