Définir et évaluer les tâches permettant de réaliser les stories. Est-ce utile ou néfaste ?


Lors de la deuxième partie du sprint planning, l’équipe revoit les stories sélectionnées dans le sprint backlog et détermine les actions à prendre pour réaliser ces stories.

Dans bien des cas, elle essaie d’identifier toutes les tâches, de la facon la plus exhaustive possible, qui seront nécessaires à l’accomplissement de la story.
En même temps elle essaie d’évaluer le temps que prendra chaque tâche. Les tâches étant découpées suffisament petites pour ne jamais depasser 2 jours hommes, on pense être en mesure d’avoir une évaluation précise.

Avons-nous besoin de ces informations ? Nous sont-elles utiles ou néfastes ?
Le besoin :
En fait le besoin exprimé pour cette information provient de notre vieille habitude de waterfall, on ne fait que transformer les sprints en mini-projets waterfall. Partant de cela on prétend avoir une analyse exhaustive et des délais parfaitement évalués.

Agir ainsi c’est un peu oublier ce qui nous amène à Scrum : reconnaitre qu’un développement de logiciel est un projet complexe d’une part, et que l’humain n’est pas habile à évaluer dans l’absolu d’autre part.

Il y a aussi un besoin de rassurance qui nous pousse à vouloir définir et évaluer : est-ce-que les stories choisies sont réalisables dans la durée d’un sprint ?
À cela deux réponses :

  • La première qui répond encore à ce besoin de plannification : Scrum, à travers l’étude statistique de la vélocité de l’équipe nous fournit un indicateur qui nous permet d’identifier le volume (en temps que complexité ) de stories qui seraient réalisables dans un sprint.
  • La deuxième sous forme de question plus philosophique : Vu que le backlog de sprint n’est absolument pas un engagement, quel est l’interêt de savoir si il est vraiment réalisable ?

Il y a aussi le product owner et le manager de l’équipe de développement qui expriment le besoin de voir que les choses avancent.
Ils disent vouloir voir que l’on est dans le temps… Dans le temps de quoi ?
Le temps lui est un élément fixe, mais dans un sprint c’est le périmètre qui est ouvert. L’équipe, elle, fait de son mieux pour réaliser un maximum de stories d’un niveau de qualité supérieure.

Et puis ultimement ce n’est pas le temps qui interesse le product owner ce sont les STORIES!
Donc la vraie métrique qui l’interesse ce n’est pas le burndown en heures mais plutôt le burnup en stories.
Le burnup en tâches est aussi une métrique interessante si on garde en tête que le découpage initial n’est pas exhaustif et qu’il s’ajoutera des tâches tout au long du sprint.

L’utilité :
Ces informations ne pourraient être utiles que dans la mesure ou elles seraient exactes.
Or elles ne peuvent être exactes que lorsque l’équipe est inchangée et collabore depuis longtemps, lorsque la technologie est maitrisée et lorsque la complexité des stories est faible et l’incertitude inexistante. Donc dans la pratique on peut affirmer que cela ne sera jamais utile ou rarement sur des projets en phase-out.

Ces informations seront en fait utiles lorsque l’on commence à adopter Scrum, elles serviront à demontrer qu’elles ne sont pas fiables et donc inutiles. C’est un peu paradoxal j’en conviens mais Je demeure convaincu que c’est une étape nécessaire de l’apprentissage et de l’appropriation de la philosophie agile scrum.

Néfastes :
Ces informations créent une pression indue et donc un stress sur l’équipe et sur le product owner. J’ai déjà lors d’un post précédent abordé le problématique du stress dans les équipes agiles-scrum, et j’avais alors expliqué le lien entre la notion de délai, de temps évalué et le stress ressenti par les membres de l’équipe.
Lorsque les membres de l’équipe débordent du temps évalué, la qualité s’en ressent immèdiatement : on tourne les coins ronds, on bacle les tests d’intègration et on oublie les tests manuels.

C’est d’ailleurs en abordant un problème de qualité par l’approche des « 5 pourquoi » que l’on a réalisé ce qui m’a amené à écrire cet article. En voici, en substance, le contenu.

Pourquoi est-ce-que la qualité n’est pas satisfaisante?
Parceque l’on n’accorde pas l’attention nécéssaire aux tests et à la qualité même.

Pourquoi on n’accorde pas l’attention ?
Parcequ’on déborde déjà du temps évalué.

pourquoi est-ce-que l’on déborde ?
Parceque l’on a sous évalué.

Pourquoi avons-nous sous évalué ?
Parceque c’est complexe et qu’on ne maîtrise pas forcement la technologie.

Pourquoi on continue à évaluer si c’est si complexe et si souvent erroné?
Pour s’assurer de se stresser inutilement ?

La solution : ne pas évaluer !

Quelle décision avons nous prise en rapport à ceci ?
Ne plus évaluer le temps des tâches, le statut « à faire », « en cours » et « fini » sera suffisant.

Faire une rétrospective positive


Depuis peu, j’ai commencé avec mes équipes à utiliser des techniques de gamestorming et de rétrospectives différentes du schéma classique afin de travailler d’autres aspects de la collaboration et de la réflexion sur le déroulement des sprints.

Celle que je vous présente aujourd’hui est une rétrospective d’appréciation, une rétrospective positive.

Première étape : Check- in (15 minutes)
Il est important, spécialement au début d’une rétrospective de donner à chacun l’occasion de s’exprimer sur l’état d’esprit dans lequel il se trouve au moment d’aborder cette rétrospective. Cela permet de voir comment le sprint a affecté chaque membre de l’équipe. On peut y aller avec un mode de jeton (chacun son tour) puis permettre à qui en ressent le besoin de revenir sur ce qui a été exprimé par ses coéquipiers.
J’accorde en général 3 minutes par personne.

Deuxième étape : mise en place (5 minutes)
Il s’agit ici d’expliquer le déroulement global de la séance de rétrospective, d’en indiquer la durée, la mécanique et l’objectif. Le temps de chacun étant précieux, il est important pour les participants de savoir que celui-ci n’est pas gaspillé, mais au contraire bien organisé et orienté vers un objectif clair.

Troisième étape : appréciation individuelle collective (10 minutes)
Chaque participant va devoir écrire un message d’appréciation à au moins un des autres participants ( finalement ils en écriront pour chaque membre). Une fois que ceci est fait, tour après tour chaque participant lit les appréciations qu’il a écrites aux autres à haute voix. Cette étape force tous les participants à interagir et met en place une logique positive.

Quatrième étape : collecte de données positives (10 minutes)
Idéalement, on dispose de post-it de 3 couleurs. On associe à ces couleurs les thèmes suivants : forces, succès et événements/moments.
Chaque participant va noter sur les post-its de la bonne couleur les éléments correspondants à ces thèmes qui se sont produits durant le sprint.
Donc il notera tout ce qui selon lui aura été des forces pendant le sprint, que ce soit au niveau personnel, équipe, environnement, processus, expert externe, outils, compagnie, collègues, etc. Même chose avec les succès et les moments ou événements marquants positifs.
Il est important de noter un seul élément par post-it.
À l’issue de cette étape, on collecte les post-its et on le colle dans un secteur du tableau blanc.

Cinquième étape : projection dans un futur utopique (15 minutes)
Présenter que l’on est à la fin du sprint suivant, et que ce sprint est le sprint de nos rêves, il n’est composé que de forces, de succès et d’événements positifs.
Quels sont-ils ?
Pour y répondre, on refait le même exercice qu’à l’étape précédente, avec les mêmes thèmes et les mêmes couleurs de post-it.
On récupère les post-its et on les place de l’autre côté du tableau.
Dans d’autres formes de rétrospective on identifie ce qui a moins bien fonctionné que ce que l’on aurait aimé, dans cette forme-ci de rétrospective, cette étape mène le participant à repenser les mêmes éléments mais en les imaginant parfaitement positifs.

Sixième étape : regroupement, mapping et collaboration (20 minutes)
On invite tous les participants à se rejoindre devant le tableau.
On leur propose d’examiner ensemble tous les post-its présents.
Ensuite, ils doivent relier, regrouper les post-its par thème, idée ou logique. ( Pas les thèmes succès forces et événement, mais plutôt des idées telles que technique, collaboration, éthique, environnement, processus… En bref ce que l’on peut déterminer depuis les post-its).
Il est normal de mélanger ce qui vient de la cinquième et ce qui vient de la quatrième étape.
Cette étape permet à chacun de prendre conscience de ce qui pour les autres est un élément positif important, on bâtit ainsi une compréhension collective des succès, des forces et des évènements importants.
En même c’est un exercice qui renforce la communication et la cohésion de l’équipe en la poussant à collaborer.

Septième étape : vote (5 minutes)
Chaque membre de l’équipe possède deux votes qu’il va pouvoir attribuer aux thèmes de ces choix. Il peut très bien décider de donner deux votes au même thème et aucun aux autres.
Sur quels thèmes voter ?
Chaque participant choisi le ou les thèmes sur lesquels il aimerait que l’équipe réfléchisse à comment en faire ou continuer à en faire des succès, des forces et des événements positifs.
On accorde quelques minutes pour faire le choix.

Huitième étape : remue-méninges à jeton (30 minutes)
On reprend les 2 thèmes qui ont remporté le plus de votes à l’étape précédente, et on rediscute tous ensemble de chacun des post-its qu’ils contiennent. On peut utiliser un système de jeton pour s’assurer que chacun aura la chance de prendre la parole sur chaque idée émise dans les post-its.
Le principe du jeton est simple, le participant qui à le jeton a le droit d’émettre une remarque ou idée sur le sujet en discussion puis il passe le jeton au suivant. Évidemment si on n’a rien à ajouter on peut « passer » et laisser le participant suivant s’exprimer. Ainsi de suite jusqu’à ce que l’on n’ait plus rien à ajouter sur le sujet on passe alors au sujet suivant.

Il faut bien entendu synthétiser ce qui sera dit à la huitième étape, identifier des éléments ( pas trop nombreux 2 ou 3) sur lesquels l’équipe veut et peut se concentrer dans son prochain sprint et clore la séance de rétrospective.

Les facteurs de stress dans le cadre de l’agilité et de Scrum et leur impact sur la performance.


Les membres de l’équipe ressentent du Stress? Mais voyons nous avons adopté l’agilité c’est Impossible !
Lorsque l’on relit les préceptes derrière Agile, scrum et xtreme programming on retrouve des éléments tels que :
– rythme de développement soutenable
– l’equipe décide de ce qu’elle pense pouvoir accomplir
– pas d’heures supplémentaires
– Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier.
– un des objectifs est de rendre le travail agréable
– avec des gens motivés
– …
Avec tout cela on peut, à juste titre, penser qu’avec l’adoption de l’agilité l’environnement de travail sera efficace et agréable, et que le stress sera absent et le plaisir omniprésent.

La réalité est toute autre, les équipes nouvellement devenues agile vivent d’intenses périodes de stress.

Qu’est ce que le stress ?
Selon wikipedia : Le stress (en anglais pression émotionnelle, de l’ancien français destresse) est l’ensemble des réponses d’un organisme soumis à des pressions ou contraintes de la part de son environnement, le tout dépendant toujours de la perception des dites pressions de la part de l’individu les vivant. Selon la définition médicale il s’agit d’une séquence complexe d’évenements se résultant en des réponses physiologiques, psychosomatiques. Dans le langage courant, on parle de stress positif (eustress en anglais) ou négatif (distress).

ON note immédiatement, que le stress n’est pas forcément négatif.

Selon de nombreuses études, il existe un lien direct entre l’intensité du niveau de stress subi par un individu et sa capacité à performer grâce à son adaptation aux changements de contraintes de l’environnement. En effet en absence de stress, l’efficacité est faible car la motivation et la mobilisation sont peu présentes; c’est ce qu’engendre la monotonie et l’absence de défi. Lorsque le niveau de stress augmente, dans un premier temps la performance augmente très significativement, on entre dans une zone ou le stress est en fait perçu comme un défi, un challenge, et devient un grand stimulateur. Lorsque le stress dépasse ce niveau et qu’il devient de plus en plus pénible de s’y adapter, la performance chute drastiquement, la motivation et la mobilisation disparaissent aussi rapidement.

La courbe suivante exprime clairement le phénomène.

Tout le défi pour l’équipe (et l’entreprise) est alors de trouver l’équilibre de stress pour maintenir un niveau de performance optimale.

Pour cela il faut d’abord identifier les facteurs de stress. Dans son étude sur le stress au travail, le docteur Patrick LÉGERON Psychiatre, praticien attaché au service hospitalo-universitaire du Centre hospitalier Sainte-Anne à Paris, nous propose le tableau suivant :

Évidemment, le gestionnaire et l’entreprise doivent être conscients de tous ces facteurs de stress et tenter de mettre en oeuvre tout ce qui permettrait de laisser place à un niveau de stress stimulant la performance.

Le Dr Légeron déclare aussi que les deux principaux facteurs sont la charge de travail et l’incertitude :

Actuellement les stresseurs les plus fréquemment retrouvés, et source des plus grandes difficultés pour les individus semblent être :
1) la charge de travail.
Celle-ci se caractérise par une quantité de travail importante à réaliser sous une forte contrainte de temps. Les interruptions de travail sont fréquentes (on parle de « zapping » des activités) : on estime ainsi qu’en moyenne un cadre est interrompu dans son travail toutes les dix minutes. Par ailleurs les objectifs à atteindre et le culte de la performance accentuent encore la pression ;
2) les incertitudes.
C’est une banalité de constater que le monde du travail est en pleine évolution. Il faut cependant souligner que l’accélération du rythme du changement est souvent associée à des incertitudes
majeures et à l’impossibilité de prévoir et donc de s’organiser. Que ce soit l’organisation de l’entreprise (fusions, restructurations, etc.) ou les technologies nouvelles (on parle maintenant du « techno-stress »), l’individu doit s’adapter sans cesse à la nouveauté et à l’inconnu.

Mais qu’en est il de notre environnement Agile ?

Dans l’article d’aujourd’hui je vais vous présenter quelques facteurs de stress provenant d’une mauvaise compréhension ou d’une mauvaise application des principes Agile-Scrum.

Premiere facteur: en rapport avec l’engagement individuel.
Les membres de l’équipe souffrent d’un attachement historique au respect des délais, si bien que l’évaluation qu’ils font des taches déclenche un sablier mental, qui fait augmenter le stress au fur et à mesure qu’on approche du délai. On retrouve ici le stresseur « Charge de travail ».
On ne veut pas décevoir ses coéquipiers ni se sentir moins « productif » que les autres, on ressent les daily sprints comme des facteurs de stress. (Stresseur lié aux difficultés relationnelles)

Autre résultante de ce comportement, on commence à tourner les coins ronds, non pas pour finir plus vite mais simplement pour ne pas trop depasser le temps évalué, et evidemment la qualité se dégrade.
En dégradant la qualité on induit deux nouveaux facteurs de stress :
– 1 : on va cumuler de la dette inévitablement, et comme on se doit d’être transparent les autres membres de l’équipe ainsi que le product owner en seront informés.
– 2 : on prend de gros risques de ne plus correspondre à la définition de fini et donc ne pas apporter de valeur durant le sprint. Comme on le sait, on vient de plus en plus stressé vis a vis de l’équipe.

Deuxième facteur: en rapport avec l’engagement collectif.
L’équipe prend le sprint backlog comme un engagement, une liste de fonctionnalités à livrer immuable. Elle se sent dans l’obligation de livrer l’ensemble du contenu. (Encore le stresseur lié à la charge de travail)
On remarque facilement ce comportement dès le sprint planning, on notera que l’équipe a tendance à vouloir en inclure moins que ce dont elle est capable afin de limiter son stress.
À vouloir absolument livrer l’ensemble, dès qu’elle rencontre des obstacles (stresseur lié à l’incertitude) et qu’elle prend un peu de retard par rapport à ce qu’elle avait envisagé, elle se retrouve dans la même position que dans la première raison et commet les mêmes erreurs avec les mêmes résultats.

Troisième Facteur : vouloir toujours faire plus et prendre l’augmentation de la vélocité pour objectif
Certaines équipes ont tendance à penser que la vélocité doit impérativement augmenter sprint après sprint pour démontrer qu’ils progressent ou tout simplement pour satisfaire leur fierté. Inévitablement l’équipe s’impose de plus en plus une charge de travail inatteignable, un rythme insoutenable, et immanquablement va se conduire à un échec et un sprint de 0 points qui, en plus d’avoir engendrer un énorme niveau de stress, va produire une grosse déception pour l’équipe.

Quatrième Facteur : des rétrospectives orientées « Performance »
Lorsque les rétrospectives sont orientées performance, on recherche à travers la rétrospective des moyens pour augmenter le volume, la quantité, la velocité. Comment en faire plus en moins de temps. Dans ces temps là on ne fait que renforcer les autres facteurs. On confond amélioration continue avec augmentation de la vélocité continue.

Comment éliminer ces 4 facteurs ?
Initialement il faut rappeler les vrais objectifs, les vrais enjeux : Livrer des logiciels de QUALITÉ et maximiser la COLLABORATION et l’APPRENTISSAGE.

Premier facteur : Il faut se rappeler que les temps évalués pour les taches ne sont pas des barrières mais des indicateurs d’ampleur sur lesquels on peut se baser pour évaluer l’avancement.
On pourrait donc changer ces indicateurs pour des valeurs comme « Petit, Moyen, Grand » ou si on veut chiffrer utiliser 4h, 8h, 16h sachant qu’une tache ne devrait pas dépasser 2 jours/homme. De cette façon on n’évalue plus les taches aussi précisément et donc on détruit le sablier mental.
La qualité étant l’objectif principal, le temps que l’on met à la réalisation d’une tache devient donc secondaire. Attention ca ne veut pas dire marginale, sinon on pourrait aller vers une dérive entraînant une vélocité très basse. Il faut aussi se souvenir que les pratiques Xtreme programming nous encouragent à rechercher la simplicité et donc les solutions les plus rapides respectant la qualité désirée. Il faut trouver l’équilibre!

Deuxième facteur : En plus de ce qui a été précisé pour le premier facteur, il faut préciser que le sprint backlog n’est pas un engagement, une liste d’éléments qui doivent impérativement être livrés mais simplement un prévision de ce qui pourrait être livré si tout le sprint se déroulait sans aucun obstacle ou évènement perturbateur.
Lorsque l’équipe a établi une vélocité historique, si la sélection respecte cette vélocité les chances de parvenir à livrer l’ensemble du sprint backlog sont grandes mais pas absolues. Ceci est tout à fait normal, l’équipe doit toujours composer avec un certain niveau d’incertitude.

Troisième facteur : le but, sprint après sprint n’est pas d’augmenter la vélocité mais de trouver quelle est la vélocité que l’équipe peut soutenir de façon constante.
Cet indicateur est essentiel au Product Owner pour évaluer le périmètre livrable dans un délai défini tout comme il est important pour la planification de l’équipe.
C’est ce message qu’il faut bien comprendre et transmettre à l’équipe.

Quatrième facteur : Se souvenir que les rétrospectives n’ont absolument pas pour objectif de trouver comment faire plus.
Ce qu’elles doivent permettre de trouver c’est comment faire mieux!
Mieux au niveau de la collaboration, mieux au niveau de la qualité, mieux au niveau des outils, mieux au niveau des interactions, mieux dans le relationnel, mieux comme plus agréable aussi, pas mieux comme plus … même si il se peut que faire mieux finisse pas faire plus ..

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.

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


Lors de la première partie je vous ai présenté comment établir la vision du projet/produit et comment établir la liste des acteurs ou personas.
Je vais maintenant continuer à vous montrer comment créer ce product backlog.

Troisième étape : les thèmes ou regroupement de fonctionnalités
Si on a accordé aux deux premières étapes tout le temps et le soin necessaire, celle-ci sera facile à accomplir.
De la vision du produit on extraira facilement les thèmes principaux, ils forment l’objectif central du produit.
Notre vision était “
Offrir une solution de gestion de location vidéo complète, incluant suivi, facturation ainsi qu’un module de prélocation en ligne et d’analyse statistique pour les vidéoclubs
“, on en tire donc facilement les thèmes suivants :

  • location et suivi
  • statistiques
  • facturation
  • prélocation en ligne

À partir des définitions des personas on peut identifier d’autres thèmes.
Par exemple la définition de bob dit ” utiliser le système pour enregistrer les locations de vidéos, ainsi que les retours de location et Comme Bob utilise le système en présence de clients qui attendent, Bob veut que le système soit rapide et facile à utiliser, une ergonomie limitant les clicks sera désirée”
On peut donc extraire :

  • retour de location (en considerant que le suivi concerne les retards)
  • ergonomie simplifiée

De la définition de Caroline ” Caroline aura la responsabilité d’installer et de configurer et de supporter le système …”
On arrive facilement à :

  • installation du système
  • configuration du système

Pour chacun de ces thèmes, il va mantenant falloir préciser certains éléments :

  • Description : plus de détail concernant le thème, peut être même une liste de sous thèmes
  • Valeur commerciale : C’est un indicateur très important qui guidera vos choix et priorités
  • Critère de satisfaction : les critères qui feront de ce thème un succès
  • Couleur de post-it : permettra de facilement identifier les stories associées
  • Utilisateurs : la liste des utilisateurs que ce thème rejoint

Comment définir la valeur commerciale ?
J’utilise la méthode suivante afin de définir la valeur commerciale de chacun des thèmes :
1. Je compte le nombre de Thèmes que je possède, et je me donne 300 points par thème.
2. Pour chaque Thème j’accorde une valeur commerciale sur 1000 points.
3. Rapidement je remarque que je n’ai pas assez de point pour tout, cela m’oblige a différencier ce qui est vraiment une valeur ajoutée de ce qui l’est moins. J’utilise alors une évaluation comparative et je remarque rapidement 3 groupes. Les incontournables, les bons thèmes et ceux dont on pourrait se passer.

Cette valeur me permet de rapidement déterminer une priorité dans l’élaboration de mon projet.
Je réutiliserai cette valeur plus tard pour calculer un ROI par thème.

Exemple de thème

À la fin de cet exercice, la liste des thèmes obtenue est plus que satisfaisante et nous fournira la base de la création du backlog.

Quatrième étape: la vision de la première release
C’est le moment de commencer à prioriser sa vision et determiner ce qui serait une solution comportant suffisamment de valeur pour etre utile.
Dans notre exemple, une vision de la release initiale pourrait etre ” Offrir un système de location et de retour pour vidéoclub”.
Cette vision va permettre de prioriser les thèmes pour lesquels il faudra ecrire des user stories prochainement.
On comprend très bien que dans notre exemple, les thèmes statistiques ou prélocation en ligne ne feront pas partie de la release initiale, on pourra donc ne pas s’attarder dessus pour le moment.

Aprés cette étape on a des éléments de reponse pour la question Quelles seront les fonctionnalités à créer ? même si pour le moment il ne s’agit que de thèmes. On commence aussi à voir une idée de réponse pour Dans quel ordre devront-elles être livrées ?

Je vais maintenant décrire un processus de création des éléments du backlog dans la troisième partie …

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


Lorsqu’une entreprise décide d’implanter l’agilité et plus précisément Scrum, le product owner nouvellement formé comprend que la responsabilité qui lui incombe maintenant représente tout un défi.

Il doit créer le product backlog initial et ensuite le maintenir, cet artefact sera l’essence du projet.
Mais par où commencer ?

les étapes de l’élaboration du product backlog que je vous présente ici permettront de répondre aux 3 questions suivantes :

  • Quelles seront les fonctionnalités à créer ?
  • Dans quel ordre devront-elles être livrées ?
  • À qui sont elles destinées ?

Au cours de ce guide nous retrouverons ces questions et leurs réponses.

Je me propose de montrer, pas à pas ce que doit construire le Product owner avant le premier Sprint planning d’un projet pour un nouveau produit. Je vais aussi présenter ma compréhension de projets itératifs qui émergent durant le processus Scrum.

Bien qu’il soit recommandé de faire ce travail en équipe, idéalement une équipe composée de gens du marketing, de gens de métier et de stakeholders (sponsors), fréquemment le Product owner fera le travail seul. Si il est issu du marketing les premières étapes ne devraient pas poser de problèmes particuliers.

Lorsque le travail est effectué en équipe, il n’est pas toujours évident de partir les séances de brainstorming. Dans l’article je présente une solution permettant d’éviter le syndrome de la page blanche lors de travail collaboratif. Cette même technique peut être appliquée à toutes les étapes de la création du backlog.
L’important à retenir de cette technique, est qu’il faut définir des délais suffisamment longs (sans exagérer) pour permettre de passer outre les réponses évidentes.

Avant de commencer, je propose de prendre un exemple simple : un système de gestion des locations vidéos.

Première étape : établir la vision du projet.
Il s’agit en quelques lignes de définir quel est l’objectif que le projet devra atteindre avant que le Product Owner n’en arrête le développement.
Il est important que cette vision soit acceptée et comprise de tous, elle doit faire consensus puisque l’équipe va devoir se rallier derrière le PO pour réaliser ce projet selon cet objectif.

Offrir une solution de gestion complète, incluant suivi, statistiques et facturation ainsi qu’un module de prélocation en ligne et d’analyse statistique pour les vidéoclubs
Bien que cela puisse paraitre simple il n’est pas évident d’obtenir de la part des sponsors l’information permettant l’élaboration de cette vision, cela nécessitera bien des rencontres.

Deuxième étape : lister les acteurs / personas.
Il va falloir identifier puis détailler tous les intervenants, utilisateurs du système dans tous ses aspects.
Pour chaque intervenant on voudra préciser les informations suivantes :

  • Surnom : donner un Surnom aux acteurs rendra plus agréable leur utilisation et il sera plus simple de s’y identifier.
  • icone / image : ajouter une représentation graphique de l’acteur rend l’identification encore plus facile.
  • rôle : c’est en fait une description courte souvent juste un mot ou nom commun
  • description : on décrit pourquoi et/ou comment cet acteur utilisera le système
  • critères de satisfaction : ce qui rendra cet acteur satisfait de l’utilisation qu’il fait du système
  • valeur commerciale : élevée, moyenne, basse, bloquante (les autres acteurs ne pourront utiliser le système)
  • fréquence d’utilisation : permanente, quotidienne, occasionnelle, rare
  • nombre d’instances : combien d’intervenants comme celui-ci utiliseront le système. 1, 10, 100+
  • niveau de connaissance technologique : élevée, moyenne, basse
  • niveau de connaissance métier : élevée, moyenne, basse

Je réaliserai seulement deux exemples ici :

  • Bob
  • une image de bonhomme
  • Commis à la location de vidéo
  • Bob utiliser le système pour enregistrer les locations de vidéos, ainsi que les retours de location
  • Comme Bob utilise le système en présence de clients qui attendent, Bob veut que le système soit rapide et facile à utiliser, une ergonomie limitant les clicks sera désirée
  • Élevée
  • Permanente
  • 10 par installation
  • Moyenne (souvent des jeunes à ce poste)
  • Élevée

Exemple de personas.

  • Caroline
  • une image de femme
  • Administratrice systéme
  • Caroline aura la responsabilité d’installer et de configurer et de supporter le système au niveau technique
  • Caroline désire une installation sans soucis, une configuration souple et simple à la fois et avant tout un logiciel fiable libre de crash
  • Bloquante
  • Rare
  • 1 par installation
  • Élevée
  • Basse

En créant les personas nous créons les éléments de réponse à la troisième question : À qui sont elles destinées ?

Dans la prochaine partie je vous parlerai des Thèmes/fonctionnalités et de la vision de release.


Voila une définition que je défend déjà. Les sponsors ont trop souvent tendance à prendre le sprint backlog comme un engagement, une liste de choses que l’équipe s’engage à realiser.

Ken Schwaber's Blog: Telling It Like It Is

Empiricism is the act of making decisions based on what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

A Product Owner plans a release based on all current information. He or she lays out the goals, the features and capabilities that will deliver those goals, and the probable cost and date of delivery. From that point on, the Product Owner’s job is to assess what is possible given the Team’s capabilities, and to make the best decisions to reach the desired goal. Given the nature of technology, markets, requirements, and people, trade-offs are made. Sometimes the goal cannot be reached for a reasonable price. Sometimes the goal will be reached, but in a way different from what the Product Owner initially intended. This is empiricism in action.

The Team…

View original post 320 autres mots