En partant du principe que vous savez ce qu’est une User Story et que vous savez comment les écrire correctement, quelques recommandations pour démarrer correctement un projet en agile ou une release d’un projet:
DĂ©marrer avec des stories Macro
Dans des projets de grande taille et particulièrement ceux qui on plusieurs type d’utilisateurs il peut être difficile de savoir par quoi commencer. Une bonne façon de faire est de déterminer quels sont les attentes de chacun des rôles. Prenons par exemple le rôle de particulier chez Quotatis. Son objectif est claire: trouver un artisan pour lui faire la pose d’un article. Mais nous pourrions aussi considéré les objectifs :
- Rechercher des artisans les plus qualifiés (proches, ayant déjà fait des travaux du même ordre, dans la gamme de prix attendu)
- Automatiser sa recherche
- Proposer de déposer une demande de pose afin que le système cherche le meilleur artisan pour l'utilisateur
- Commander facilement une pose pour un artisan donné
L’objectif principal ainsi que les sous-objectifs peuvent être les premières US du backlog
DĂ©couper le gateau
Sur la base de ces premières stories, il faut ensuite découper en stories plus petites. A cette étape il faut faire attention a ne pas se faire influencer par l’équipe technique qui serait tenter de découper une story « Le particulier dépose une demande de travaux » en:
- Le particulier remplit un formulaire de demande de travaux
- Le chantier est enregistrer en base de données
Ce découpage n’est pas bon à plusieurs titres: la première US n’est donc pas enregistré en base? Cela implique qu’elle n’apporte aucune valeur à l’utilisateur et donc qu’elle n’est pas valuable (cf. INVEST). La seconde story quant à elle n’est pas fonctionnelle mais technique. D’autre part elle est dépendante de la première et n’est donc pas Indépendante (INVEST)