Definition of ready

Definition of ready : Liste de conditions qu’un élément du backlog doit remplir avant d’entrer en développement, pour éviter les blocages en cours de sprint.

Entrée de la famille « Produit et UX » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Ce que recouvre Definition of ready, concrètement

Definition of ready appartient au langage commun du client et de l’équipe de conception. C’est souvent le premier mot qui manque quand une recette tourne au malentendu.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

De la définition à la ligne de cahier des charges

Un cahier des charges qui traite « Definition of ready » sérieusement décrit aussi les cas qui vont mal : état vide, erreur, connexion perdue, droits insuffisants. C’est un tiers du travail réel.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le parcours principal, décrit du premier lancement à la première action utile.
• Les critères d’acceptation, rédigés de manière à pouvoir être refusés.
• Le nombre d’allers-retours de maquettes inclus dans le prix.
• Le niveau d’accessibilité visé, et les écrans sur lesquels il est vérifié.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

À la recette, « Definition of ready » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Reprendre les critères d’acceptation et les cocher un par un, sans indulgence.
• Utiliser l’application sur un petit écran, d’une seule main.
• Parcourir l’écran principal au lecteur d’écran, au moins une fois.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
• Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
• Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
• Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Observation contextuelle
• Registre des traitements
• MVP
• Onboarding
• Churn

Questions fréquentes

Que signifie « Definition of ready » ?

Liste de conditions qu’un élément du backlog doit remplir avant d’entrer en développement, pour éviter les blocages en cours de sprint. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.