Comment découper une User Story ? Votre question agile (qui concerne aujourd’hui le découpage des user stories)… ma réponse de coach agile !
Parce que vous attendez aussi des réponses ! (cf . la posture spécifique du coach agile – The Profession of the Agile Coach – Article en anglais). Dans mon livre Scrum, chapitre Structurer le backlog, page 74, je présente le workflow de la story.
Extraits : En 2001, Ron Jeffries définissait la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C » . En fait, avec Scrum, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour qu’elle soit finie. On passe à 5C : En se basant sur ces « 5C », on obtient le workflow de la story : Mais quel est donc ce 6e C sur la carte heuristique ? Dans son excellent livre Le Story Mapping, page 122 dans la version française, Jeff Patton s'appuie aussi les 3C, différemment car il ne se réfère pas à Scrum.
Début juin 2015, en pleine écriture de mon livre, je n'avais encore que 4D et demi.
Dans l'édition 4, il y a bien les 6, pages 82 et 83, chapitre Affiner le backlog. Voici l'extrait qui en cause : C’est l’équipe qui décide si une story est prête. Pour prendre sa décision, elle pourra s’appuyer sur une liste de vérifications, la définition de prêt. La définition de prêt est élaborée par l’équipe et dépend du contexte. Backlog et workflow des stories. Le backlog contient des éléments, qui ont chacun leur cycle de vie.
Pour être plus explicite, plutôt qu'élément du backlog de produit, j'utilise story. Le backlog de produit contient donc des stories. La vie d'une story se déroule de la façon suivante : un jour, elle est suggérée par quelqu'un qui a une idéele Product Owner, qui est finalement le responsable du contenu du produit, examine les stories suggérées et les acccepte -ou pas- pour qu'elles soient développées et ajoutées au produitUne fois acceptées, les stories sont estimées par l'équipe qui évalue l'effort de développement nécessaireLes stories peuvent alors être planifiées, c'est à dire associées aux sprints dans lesquels on prévoit de les réaliserLorsqu'arrive le sprint, les stories qui y sont associées deviennent "en cours"Et si tout se passe bien, elles seront finies à la fin du sprint. Les types de story dans un backlog. La vocation du backlog étant de collecter tous les travaux de l'équipe qui apportent de la valeur, il n'est pas raisonnable de se limiter uniquement à ce qui est visible des parties prenantes.
Cette présentation des types de story reprend l'idée de Backlog in Colors proposée par Philippe Kruchten (qu'on trouvera dans ses slides sur la dette technique dont je conseille la lecture; elle donne du sens à cette notion souvent vague). Elle se base sur 4 quadrants avec deux axes : selon que la story ajoute de la valeur ou rétablit celle perdue,selon que cette valeur est perceptible par les parties prenantes externes à l'équipe (valeur "métier"), ou seulement par l'équipe (valeur aussi, mais pas directement "métier").
DÉCOMPOSE la story. Je m'amuse à trouver des noms parlants ou des acronymes faciles à retenir pour désigner les patterns que je mets en évidence dans la 5e édition de mon livre Scrum.
Je suis content du dernier que je viens de trouver. Après les 6D, ADAPTER, PROUVÉ, voici DÉCOMPOSE, le pattern qui donne des pistes pour décomposer une story. Critères VRAC pour la priorité dans le backlog. Prioriser est un néologisme souvent utilisé, et pas que pour un backlog.
Avec Scrum, on dit que le PO priorise les éléments du backlog. Bien qu'en fait, il les ordonne. Mais sur quels critères se base t-on ? Dans l'édition 4 de mon livre, chapitre Affiner le backlog, § Revoir l’ordre, page 89, je résume ainsi : L’ordre (ou priorité ordinale) correspond au rang définissant la séquence de réalisation des stories.
Backlog : critères pour établir les priorités. Un des points forts de Scrum est le backlog de produit, qui regroupe toutes les exigences, ce qui facilite leur gestion.
Il est -techniquement- simple de définir les priorités entre les éléments du backlog. Mais sur quels critères se baser ? Il faut d'abord bien comprendre que la priorité correspond à l'ordre de développement. Ce ne sont pas 2 notions différentes. La priorité est souvent comprise autrement -que pour définir le contenu des itérations-(voir ce billet précédent), tant qu'on n'a pas pratiqué Scrum.
User Story... L'essentiel en 5 images. En direct de mes sessions de perfectionnement destinées aux Product Owners… Pour plus de détails sur le contenu de chaque image, vous trouverez votre bonheur dans cet article : « User stories: Back to Basics » D’autres articles pour nos chers PO: Jean Claude GROSJEAN - COACH d’Organisation.
Coach d'Equipes - Coach Agile. Quand estimer les User Stories? Votre question agile (qui concerne aujourd’hui l’estimation des user stories)… ma réponse de coach agile !
