La réponse courte
Une bonne user story Salesforce décrit qui est l'utilisateur, ce qu'il essaie d'accomplir, et ce qui sera vrai après l'action – plutôt que de spécifier quel champ apparaîtra sur quel écran. Le test simple : si les critères d'acceptation peuvent être rédigés sans savoir si l'implémentation se fera via Flow, une règle de validation ou Apex, alors la story est correctement formulée.
L'erreur courante est d'inclure déjà la solution dans la story. Dès qu'il est écrit "ajouter un champ de picklist à l'écran d'opportunité", la discussion sur le processus est close avant même d'avoir commencé.
Une structure efficace
| Composant | Rôle | Critère de qualité |
|---|---|---|
| Contexte | Qui est l'utilisateur et quand agit-il | Rôle réel, pas juste "utilisateur" |
| Intention | Ce qu'il essaie d'accomplir | Formulé dans le langage métier |
| Critères d'acceptation | Ce qui est vérifié | Peut être exécuté comme un scénario avec des données de test |
| Cas limites | Ce qui échoue intentionnellement | Au moins un cas négatif |
| Hors périmètre | Ce qui est explicitement exclu | Prévient les désaccords lors de l'acceptation |
La dernière ligne évite la plupart des conflits. Une déclaration explicite que ce qui n'est pas inclus est effectivement exclu vaut plus que trois paragraphes de description.
Découpage : Vertical Slice plutôt que par couches
La tentation dans un projet CRM est de découper par composants techniques – d'abord le modèle de données, ensuite les automatisations, enfin les rapports. Le résultat est qu'il n'y a rien à montrer avant la fin, et personne ne sait si le processus fonctionne.
Le bon découpage est vertical : un scénario complet, de bout en bout, pour un profil utilisateur donné. Une opportunité qui est ouverte, progresse, est clôturée et apparaît dans un rapport – cela vaut plus que dix objets définis sans processus. Par la suite, on ajoute des profils et des scénarios autour de ce squelette.
Prioriser quand tout est urgent
Trois critères suffisent, dans cet ordre :
- Bloque-t-il le déploiement ? – Sans cela, le processus est incomplet. Il n'y a pas de marge de négociation.
- Combien d'utilisateurs par jour ? – La fréquence l'emporte sur l'intensité de la plainte. Un élément qui touche 80 représentants par jour prime sur la demande d'un seul manager.
- Quel est le coût du report ? – Le coût de l'implémentation augmente-t-il si nous le faisons après le lancement ? Un changement dans le modèle de données oui, un changement dans un rapport non.
Ce qui ne passe pas ces trois critères est déplacé vers le Parking Lot. Cette séparation évite un backlog qui se transforme en archive de souhaits. Une analyse approfondie de la gestion du changement d'étendue est disponible dans Scope Creep et contrôle des modifications.
Dette de spécification : l'échec silencieux
La dette de spécification se crée lorsqu'une story est clôturée sans qu'il ait été décidé ce qui se passe dans le cas limite – on se dit "on s'en occupera plus tard". Après le déploiement, ces cas limites représentent la majorité des appels au support.
La discipline simple : un élément n'est pas clôturé sans une décision documentée pour chaque question ouverte qui y a été enregistrée, même si la décision est "ne pas le traiter intentionnellement". Documenter la renonciation vaut mieux que l'absence de documentation.
Lien avec les tests
Des critères d'acceptation correctement rédigés sont en fait les scripts de UAT. Lorsqu'ils sont écrits après le développement, le UAT devient une démonstration de ce qui a été construit plutôt qu'une vérification de ce qui était requis. La séquence est détaillée dans le guide UAT.
Résumé
Un backlog de qualité n'est pas long mais clair : chaque élément indique à qui il est destiné, ce qui sera mesuré comme un succès, et ce qui est explicitement non inclus. Ces trois questions, posées avant la construction et non après, déterminent presque toute la qualité de l'acceptation à la fin du projet.