Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

DOR v2.1 Leasa Cheat Sheet by

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 foncti­onn­alité couvrira l’obje­ctif/ le besoin métier
NÉGOCIABLE DANS LE FOND
L’équipe est libre pour définir comment la foncti­onn­alité sera implém­entée techni­quement
NÉGOCIABLE DANS LE TEMPS
L’équipe peut, en échangeant avec le Product Owner discuter de la priori­sation 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 FONCTI­ONN­ELLE), 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 FONCTI­ONN­ELLES aux parties prenantes métier (client, utilis­ate­urs...) et validée (si la taille de l'US assez importante foncti­onn­ell­ement)
 

Estimable

MAQUETTES DISPON­IBLES
Des maquettes à jour ou un zoning est dispon­ible. Le Design System a la respon­son­sab­ilité 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éf­ice­]"
SPÉCIF­ICA­TIONS
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 foncti­onn­alité adresse le mobile, ou le Desktop FrontO­ffice. 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 comple­xité) par toute l'équipe de manière fiable (taille cohérente par rapport aux étalons, faisab­ilité technique vérifiée) La catégo­ris­ation doit être récente (< 6 mois), pour ce faire un rituel de revue des catégo­ris­ations des tickets > 6 mois est instauré
 

Indépe­ndant

SYNCHR­ONI­SATION PARTEN­AIRES
J’ai à ma dispos­ition à minima les contacts à jour des différents parten­aires extérieurs liés au projet et je peux me synchr­oniser avec eux
DÉPEND­ANCES / ADHÉRENCES IDENTI­FIÉES
Les adhérences sont identi­fiées : Il n’y a pas d’adhé­rences OU Elles sont identi­fiées et correc­tement gérées
TÂCHES TECHNIQUES
Les tickets "­arc­hit­ecture techni­que­" de la US sont créés si besoin et planifier au Sprint précédent les devs de l'US

Testable

CRITÈRES DE PERFOR­MANCE
Si applic­able, des critères de perfor­mance testables sont définis pour les nouvelles US si l'écran est considéré comme fort potentiel d'util­isation
SCÉNARIOS RÉDIGÉS
Des scénarios d’util­isation à minima sous forme de workfl­ow/­dia­gramme d'activité décrivent l’inté­gralité des cas d’util­isation de la foncti­onn­alité
 

Rentre dans le Sprint

Suffis­amment petit
La taille du Ticket Jira (et du nombre de points de comple­xité) est suffis­amment petite pour être complè­tement terminée en un seul sprint
Suffis­amment grand
La taille du Ticket Jira (et du nombre de points de comple­xité) est suffis­amment 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)
   
 

Metadata

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          PivotalTracker Search Cheat Sheet
          Certified Agile Project Manager (IAPM) Cheat Sheet
          Certified Senior Agile Project Manager (IAPM) Cheat Sheet