Cheatography
https://cheatography.com
DOR v2.1 Leasa DOR v2 Leasa
Negociable
NÉ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) |
|
|
Estimable
MAQUETTES 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épendant
SYNCHRONISATION 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 |
Testable
CRITÈ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 Sprint
Suffisamment 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