background preloader

Stories

Facebook Twitter

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. 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.

Backlog et workflow des stories

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.

Les types de story dans un backlog

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"). Critères VRAC pour la priorité dans le backlog. Prioriser est un néologisme souvent utilisé, et pas que pour un backlog.

Critères VRAC pour la priorité dans le 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. La valeur est la somme de la «valeur métier» et de la «valeur de connaissance», ce que la story permet d’apprendre, permettant de réduire un risque fonctionnel ou technique.La taille est celle qui est estimée dans l’activité précédente.Les dépendances sont de trois sortes, elles portent sur d’autres stories, sur les gens qui peuvent réaliser la story, ou sur une échéance temporelle. Pour se souvenir de ces critères, j'avais testé le moyen mnémotechnique V2TD3. En adaptant légèrement, voici VRAC : La formule (V+R+A)/C ne peut pas être utilisée de façon mécanique. 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.

Backlog : critères pour établir les priorités

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. Sur quels critères baser les priorités ? Il y a sur ce sujet une différence entre les approches type UP (RUP et OpenUP) et les approches agiles (Scrum). Dans les premières, le contenu des itérations est guidé par les risques. Dans la pratique, je conseille de tenir compte de la position dans le cycle de vie : Un bon product owner fixe les priorités en :

QualityStreet - Blog Agile depuis 2007. 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.

QualityStreet - Blog Agile depuis 2007

Coach d'Equipes - Coach Agile.