|
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)
|
|
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é
|
|
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
|
|
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é
|
|
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)
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
