Petit guide pour Scrum Product Owner : Comment démarrer son product backlog partie 3/3


Dans les parties précédentes je vous ai présenté les étapes préliminaires à la création du product backlog.
Je vais maintenant vous parler des éléments du backlog à proprement dit, les « user Stories ».

Que sont les Les users stories ?
Ce sont les spécifications du projet présentées sous forme d’histoires utilisateurs qui décrivent les interactions de l’utilisateur avec le système de façon plus ou moins détaillées.

Comment se présente une user story ?
la partie principale est l’histoire elle même, je l’écris sous la forme suivante :
« En tant que ,
Je peux
Afin  »

Si on reprend notre ami Bob, on pourrait donc avoir une user story comme celle-ci :
« En tant que Bob,
Je peux Créer un compte client,
Afin de pouvoir leur louer des films »

ou bien

« En tant que Bob,
Je peux entrer une location,
Afin d’avoir une trace »

La rédaction d’une user story se doit de repondre au critères INVEST (independant, negotiable, valuable, estimable, small, testable)

  • Independant (indépendante) : Une user story se doit d’être indépendante de toutes les autres stories. En prenant cette définition à l’envers on la comprend mieux, une user story se doit de n’avoir aucune dépendance envers les autres stories, elle doit pouvoir être réalisée sans individuellement. Ce besoin découle du fait qu’à tout moment on veut pouvoir réorganiser, reprioriser le product Backlog. Si les stories ont des dépendances, cette repriorisation est limitée.
  • Negotiable (négociable): Toute story qui se trouve dans le backlog de produit, peut etre réécrite, repensée ou même supprimée à tout moment en raison de changements du marché, de modification de l’orientation de besoins techniques ou tout autre motifs valable provenant de membre de l’équipe ou des sponsors.
  • Valuable (valeur métier) : Toutes les stories se doivent de générer de la valeur pour l’utilisateur final. À cet effet, les stories techniques, bien que le fun à coder ou parfois nécessaires, n’apportent aucune valeur métier et ne devraient donc pas exister ou être incluses dans des stories régulières. On Essaiera donc de les limiter
  • Estimable : Une user story doit pouvoir être évaluée en terme de complexité par l’équipe. Si une user story ne peut être évaluée, elle ne sera jamais planifiée ni incluse dans un sprint backlog ou découpée en taches. Habituellement elle ne peut l’être lorsqu’elle manque d’informations de support, ou lorsque la description faite pas le Product Owner est insuffisante ou vague.
    Une catégorie particulière de story : Les epics ne peuvent être évaluée puisqu’elles représentent en fait un ensemble de stories, dans ce petit guide les Thèmes remplissent le même besoin. Vous pouvez toutefois les utiliser comme pense-bête.
  • Small (Petite ou de taille appropriée): Une user story doit être suffisamment petite pour permettre d’être évaluée avec le plus de précision et certitude possible. Si l’équipe évalue la complexité relativement élévée, cela démontre en général un niveau d’incertitude élevé et cela implique qu’elle devrait être découpée en plusieurs stories.
  • Testable : Garder en tête qu’une story ne peut être considérée finie sans qu’elle ait été testée avec succès. Si il n’est pas possible de tester la story due à un manque d’information, elle ne devrait surtout pas être considerée pour être incluse dans un sprint Backllog. Ceci est encore plus vrai pour les équipes intégrant les techniques XP et particulierement le TDD (développement piloté par les Tests).

Si une user story répond à tous ces critères sa place dans le product backlog est tout à fait justifiée. Il ne restera donc plus qu’a la prioriser.

En plus de l’histoire elle même, certaines informations utiles peut être ajoutées pour la définition de la story ce qui donnera comme ensemble :

  • Thème : Le théme auquel cette story est reliée. Utiliser un postit de la couleur définie dans le thème permet de rendre le backlog plus visuel.
  • Acteur : L’acteur ou personas utilisé pour rédiger la user story. La encore si c’est possible utiliser l’icone rend l’ensemble plus visuel
  • story : utilisée lorsqu’il s’agit d’une user story.
  • Description : utilisé lorsqu’il s’agit d’une story technique ou d’un bug
  • Valeur : La valeur métier, on pourra utiliser le même genre de principe que celui présenté pour les thèmes.
  • Complexité : Sera évaluée par l’équipe lors des sprint plannings ou des rencontre de travail du backlog produit (optionnelles)
  • ROI : le retour sur investissement se calcule simplement = Valeur/Complexité. C’est un indicateur intéressant pour prioriser le backlog.
  • Tests d’acceptation : permet de définir quels seraient les tests d’acceptation de la story.
  • Commentaires :
  • Apect itératif de la création et définition du product Backlog :
    Plus un élément du backlog est priorisé et donc proche d’être inclus dans un sprint plus il se doit d’être détaillé, estimable et petit.
    A contrario, tant qu’un élément du backlog est de faible priorité il nécessite moins de détail et peut rester plus vague. On va donc au fur et à mesure de la montée en priorité définir et decouper les stories en éléments plus clairs et plus petits.

    Donc, en basse priorité on pourrait retrouver « gerer les clients » qui rendu en pkus haute priorité sera decoupé en ajouter un client, modifier un client, supprimer un client …. ceci n est qu’un exemple.

    Pour l’aspect emmergence itérative, on pourra identifier les transactions centrales du système, comme dans notre exemple ce pourrait être l’écran de location de films dans lesquels tous les élements devraient être saisis manuellement, puis on creera la gestion de la bibliothèque de films et on en utilisera les données dans la location, puis la gestion des clients et on l’utilise dans les transactions de location.
    C’est ce que j’appelle un développement à itérations centrique autour des fonctionnalités majeures du système.

    Voila, j’espère que ceci vous éclaire un peu et vous permettra de vous préparer pour votre premier sprint planning.

    Advertisements

Durée des sprints : deux, trois ou quatre semaines ?


Je vois souvent des équipes qui se demandent quelle devrait être la durée de leurs sprints ? Deux, trois ou quatre semaines ?
En fait pour répondre à cette question, il faut d’abord comprendre quelles sont les differentes variables qui influencent ce choix.

Première variable : la taille de l’équipe.
On le sait, les équipes scrum doivent être constituées de 3 à 9 membres. On parle tout de même d’un ratio du simple au triple.
Des équipes de 3 personnes ont évidemment une capacité de développement moindre, partant de cette idée, des sprints courts ne permettront pas suffisament d’ajout de valeur, les sponsors (stakeholders) risquent de perdre interet pour les sprint review.
À l’opposé, de grosses équipes utilisant des sprints longs, vont produire beaucoup de valeur à chaque sprint et necessiter beaucoup de travail de plannification en amont des sprints. Il permettrons aussi moins de changements à faible coût.

Deuxième variable : l’experience de l’équipe
Si il s’agit d’une équipe qui a peu d’experience tant au niveau de l’approche agile qu’au niveau du travail collectif, des sprints plus courts entraineront une plus grande fréquence des sprint retrospective. Plus une équipe est jeune, plus les retrospectives, si elles sont bien conduites et si on applique les pistes d’améliorations que l’on y découvre, sont importantes. Elles sont l’élément principal de l’amélioration continue de l’équipe.
Pour une équipe plus aguerrie, le besoin d’amélioration est moins présent on peut donc se permettre d’étirer un peu les sprints.

Troisième variable : la disponibilité du Product Owner
Plus les sprints sont courts, plus les meetings de sprint planning, sprint review et sprint retrospective sont fréquents, bien qu’ils soient de durées proportionnelles au sprint, plus ils sont fréquents plus c’est demandant pour le po.
Un Product owner qui gererait plusieurs projets ou équipes aurait beaucoup de difficulté à tenir le rythme.
À l’opposé un po qui ne gère qu’une seule équipe pourrait trouver des sprints de 4 semaines beaucoup trop longs et manquant d’interaction.

Quatrième variable : le besoin de changement, de réactivité
Lorsque le projet nécessite une plus grande réactivité dûe à une compétition plus féroce, un domaine jeune en plein évolution, des sprints courts offriront au Product Owner la souplesse nécessaire pour assurer une grande compétitivité.

Sachant qu’il est peu recommandé de changer la durée des sprints en cours de release, avant de définir celle-ci, verifiez ces variables pour vous assurer le bon choix.

Les pieges pour une jeune équipe agile : la perte de focus, l’écart à la définition de fini


Lorsqu’une compagnie décide de prendre le virage de l’agilité, ses équipes de developpement font face à de nombreux pièges.
Bien sur l’ajout de scrum master experimentés aiderait grandement à prévenir l’équipe face à ces pièges, la réalité est que dans la plupart des cas l’entreprise va vouloir effectuer cette transition avec les effectifs déjà en place.
Dans cette optique il est impératif de former des employés à certains des rôles importants d’une équipe scrum.

1: un Product Owner, il faudra déjà identifier la bonne personne, quelqu’un qui connait le metier, les attentes du marché. Une personne qui allie à la fois des compétences techniques et commerciales serait idéale.

2: Des scrum master, il faudra prevoir deux scrum master par équipe afin qu’ils puissent se valider et se surveiller l’un l’autre pour s’assurer que celui qui jouera le role pendant le sprint n’oublie rien et ne devie pas du processus. On leur donnera le rôle en alternance de 2 ou 3 sprints.

Dans notre cas, j’ai suivi les deux formations, je joue donc le role de PO mais aussi celui de facilitateur et de coach agile auprès de l’équipe et des scrum masters.
C’est ce qui me permet de déceler les pièges dont je vais vous parler.

Le premier que je vous présente est la perte de focus.
Il faut se rappeler qu’un des objectifs du processus scrum est de maximiser la valeur de ce qui est créé en éliminant le superflus.
Pour les programmeurs qui ont une longue experience de développement waterfall, l’élimination du superflus n’est pas du tout une habitude.
Et dans le pire cas cela risque de se présenter comme suit :
Votre Product Owner va construire un backlog priorisé allant à l’essentiel.
L’équipe selectionnera ce qu’elle peut réaliser dans le prochain sprint en respectant les priorités du po.
Le sprint commence l’équipe ajoute des tâches reliées aux stories mais certaines de ces taches vont au dela de ce que decrivent les stories, elle en vient a fabriquer un marteau pneumatique pour écraser une mouche.
Elle anticipe sur ce qu’elle pense que le po priorisera pour les prochains sprints.
Et puis l’équipe identifiera des taches « urgentes » pour répondre à des besoins technologiques et réalisera ces tâches au dépend de celles nécessaires aux stories.

Le deuxième est l’écart à la définition de fini :
L’équipe oublie de se referer à la définition de fini pour valider que les stories qu’elle considère terminées le sont bel et bien.
Unvou plusieurs des éléments ne correspondent pas. Par exemple on oublie de valider un des browsers sélectionnés.

Résultat : peu ou pas de stories sont considerées finies.
Est-ce-que ce sprint est un echec ? Absolument pas, il est une source d’enseignements considérable !

Maintenant que l’on a identifié ces pièges, on peut trouver des pistes de solutions.
1- lors de chaque création de tâche reliée à une story, relire la story ET la définition de fini et se poser la question suivante « Comment cette tâche m’aide-t-elle à terminer cette story ?  »
Si la réponse n’est pas évidente, pourquoi réaliser cette tâche ? Plutôt se reposer la question « Comment finir cette story ou comment la finir mieux ou différemment ?

2- lors de l’ajout de tâches « urgentes » non reliées directement à une story, se poser la question suivante « Quel obstacle qui bloque la réalisation de stories de ce sprint cette tâche va-t-elle permettre d’éliminer et comment pourrais je le faire sans cette tâche ou avec une meilleure approche? »
Si la tâche demeure la meilleure option … go for it !
Sinon il faut se poser la question suivante  » Comment cette tâche va me permettre de réaliser les stories plus rapidement et m’assurer de les finir dans ce sprint et comment pourrais je faire autrement ou mieux ? »

Si la tâche ne demeure pas un réel levier dès ce sprint, bien qu’elle puisse être justifiée elle n’est pas urgente et devrait etre réevaluée et repriorisée avec le PO.

3- En tout temps chercher le chemin de moindre résistance permettant de créer la valeur ajoutée attendue par la story en éliminant le superflu.

4- Imprimer la définition de fini et la mettre très visible dans un lieu de passage ou bien exposée sur chaque cubicule afin qu’on s’en impreigne.

5- Se faire de mini démos en cours de sprint entre les membres de l’équipe pour valider l’aspect fini de chaque story terminée.