Cheatography
https://cheatography.com
DOR v2.1 Leasa DOR v2 Leasa
NegociableNÉGOCIABLE DANS LA FORME | L’équipe peut, en échangeant avec le Product Owner, discuter de la manière dont la fonctionnalité couvrira l’objectif/ le besoin métier | NÉGOCIABLE DANS LE FOND | L’équipe est libre pour définir comment la fonctionnalité sera implémentée techniquement | NÉGOCIABLE DANS LE TEMPS | L’équipe peut, en échangeant avec le Product Owner discuter de la priorisation de la User Story | NÉGOCIABLE DANS LE FOND | La User Story dont le ticket fait parti a été présentée (si besoin) à l'équipe par le Product Owner (TEAM FONCTIONNELLE), challengée et acceptée par l'ensemble des membres de l'équipe | BESOIN MÉTIER VALIDÉ | La User Story a été présentée par la TEAM FONCTIONNELLES aux parties prenantes métier (client, utilisateurs...) et validée (si la taille de l'US assez importante fonctionnellement) |
| | EstimableMAQUETTES DISPONIBLES | Des maquettes à jour ou un zoning est disponible. Le Design System a la responsonsabilité du style | LIBELLÉ CLAIR ET FORMALISÉ | Le corps (et non le titre) du ticket (US) est clair et formalisé selon la formule "En tant que [rôle], je veux [action] afin de [bénéfice]" | SPÉCIFICATIONS | Le besoin a été spécifié : Des règles de gestion sont exprimées | CHOIX DU DEVICE | La flotte concernée par le besoin a été définie : nous savons si la fonctionnalité adresse le mobile, ou le Desktop FrontOffice. Sur Jira : dupliquer la story et vérifier que dans le libellé et le composant Jira MOBILE/FRONT apparaisse et lier les ticket via un lien | TAILLE RELATIVE FIABLE | Le ticket a été estimé en taille relative (Points de complexité) par toute l'équipe de manière fiable (taille cohérente par rapport aux étalons, faisabilité technique vérifiée) La catégorisation doit être récente (< 6 mois), pour ce faire un rituel de revue des catégorisations des tickets > 6 mois est instauré |
| | IndépendantSYNCHRONISATION PARTENAIRES | J’ai à ma disposition à minima les contacts à jour des différents partenaires extérieurs liés au projet et je peux me synchroniser avec eux | DÉPENDANCES / ADHÉRENCES IDENTIFIÉES | Les adhérences sont identifiées : Il n’y a pas d’adhérences OU Elles sont identifiées et correctement gérées | TÂCHES TECHNIQUES | Les tickets "architecture technique" de la US sont créés si besoin et planifier au Sprint précédent les devs de l'US |
TestableCRITÈRES DE PERFORMANCE | Si applicable, des critères de performance testables sont définis pour les nouvelles US si l'écran est considéré comme fort potentiel d'utilisation | SCÉNARIOS RÉDIGÉS | Des scénarios d’utilisation à minima sous forme de workflow/diagramme d'activité décrivent l’intégralité des cas d’utilisation de la fonctionnalité |
| | Rentre dans le SprintSuffisamment petit | La taille du Ticket Jira (et du nombre de points de complexité) est suffisamment petite pour être complètement terminée en un seul sprint | Suffisamment grand | La taille du Ticket Jira (et du nombre de points de complexité) est suffisamment grand ne pas générer du travail inutile sur un ensemble de tâche du même sujet (cf. tickets à 1, 2 voire 3) |
|
Created By
Metadata
Comments
No comments yet. Add yours below!
Add a Comment
Related Cheat Sheets