Biais Cognitif d’insensibilité à la taille de l’échantillon

L’insensibilité à la taille de l’échantillon est un biais cognitif qui se produit lorsque les gens estiment la probabilité d’un résultat ou situation en se basant sur les résultats sur un échantillon sans égard à la taille ni à la représentativité de cet échantillon.

En quoi sommes-nous concernés dans nos projets ?

Tous vos clients ou prospects sont-ils identiques ?

Il arrive souvent que l’argument de « la voix du client » soit utilisé par vos parties prenantes pour justifier leurs choix ou les priorités qu’elles souhaitent voire satisfaites par votre projet. Et la voix du client est utile et doit être entendue. Parler avec les clients est important, mais ne basez pas vos suppositions sur les priorités des fonctionnalités de vos livrables sur seulement quelques entretiens. Plus l’échantillon est faible et plus la variation risque d’être grande.

Comment éviter le plus possible ce travers ?

Vous savez que le choix et la taille de l’échantillon sont primordiaux pour contrer le biais cognitif lié à notre insensibilité naturelle envers ces aspects. Efforcez-vous, avec l’équipe, de prendre en compte la taille et les caractéristiques de votre panel. Placez davantage d’efforts en amont sur les critères de sélection de l’échantillon. Travaillez avec de très nombreux clients et basez votre priorisation et vos décisions de produit sur des données factuelles plutôt que des suppositions ou des extrapolations basées sur les réponses d’une poignée de clients.

Ce biais peut-il nous être utile ?

Votre attention bienveillante à la qualité des échantillons choisis pour justifier les décisions de projet va rapidement infuser le projet, vos parties prenantes et vos équipes. Vous pourrez, après avoir enraciné les bonnes pratiques sur l’aspect quantitatif de ces échantillons, commencer à introduire l’aspect qualitatif. Par exemple, les clients choisis pour cette enquête terrain sont-ils bien représentatifs de la cible marketing visée ? Localisation, taille, usages, processus, secteurs économiques… Ne limitez pas vos enquêtes ou entretiens à des questionnaires à choix multiples, utilisez davantage de questions ouvertes pour que les répondants s’expriment pleinement.

Enfin, en utilisant des approches Agiles comme Scrum, validez les premiers livrables de vos itérations (ou sprints) avec vos clients pour avoir des retours concrets immédiats et infléchir ou corriger votre direction rapidement.

CertYou est partenaire de DantotsuPM

Le guide Scrum 2020 : De nombreux articles et commentaires d’experts francophones

Depuis son arrivée,  en novembre 2020, le guide suscite bien des commentaires.

Le nouveau Scrum Guide : Sa page de téléchargement GRATUIT dans la langue de votre choix

Voici des billets qui m’ont intéressé et parfois surpris…

Bruno Margueritat avec un résumé et une analyse personnelle de cette nouvelle version du guide : http://brunomargueritat.com/2020/11/18/scrum-guide-2020/

Claude Aubry exprime son premier ressenti à la lecture de la version française (qui a été depuis améliorée) et son analyse critique des différences et des apports de cette nouvelle mouture :

  1. Premier ressenti
  2. Critique plus étayée

Pablo Pernot nous provoque un peu et nous force à prendre du recul avec son billet au titre choc: Difficile fin de carrière pour Scrum

Pour rappel

CertYou est partenaire de DantotsuPM

billets les plus lus en Décembre 2020 sur DantotsuPM.com : Chemin Critique, Meilleures conversations et nouveau guide Scrum

Des sujets variés ont été les plus lus ce mois de Novembre: Techniques avec Critical Path et le nouveau Guide Scrum, ou bien leadership avec l’amélioration des conversations pour les leaders.

4 idées fausses sur le Chemin Critique (Critical Path)

La plupart des personnes non-techniques ne savent pas ce qu’est le chemin critique. Celles travaillant sur des projets informatiques savent ce que cela signifie à un haut niveau, mais ont une faible compréhension de sa réelle mécanique et comment elle peut rapidement changer le résultat de leurs projets !

La vérité est qu’il y a beaucoup d’idées fausses sur chemin critique. Démystifions certaines des principales.

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Le guide Scrum 2020 est paru le 18 Novembre

  1. Guide téléchargeable gratuitement

    Moins prescriptif : Scrum est ramené à un cadre minimal suffisant

  2. Objectif de Produit, le « Pourquoi »: Chaque Sprint devrait rapprocher le produit de son objectif global.
  3. Élimination des comportements « proxy » : Une seule équipe Scrum concentrée sur un même objectif de produit avec 3 différents jeux de responsabilités : Product Owner, Scrum Master et développeurs.
  4. Engagements et auto-gestion : Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done. La version 2020 met l’accent sur une Scrum Team autogérée qui choisit qui, comment et sur quoi travailler.
  5. + Lean : En effet, moins de 13 pages que je vous engage à lire et relire…
CertYou est partenaire de DantotsuPM

10 façons d’avoir de meilleures conversations pour un(e) leader

Quel message vos paroles envoient-elles, chers leaders ? Améliorez vos compétences de communication chaque jour avec ces « petites » astuces.

CSP est partenaire de DantotsuPM

 

billets les plus lus en Octobre 2020 sur DantotsuPM.com : PDCA, User Stories et Product Owner

L’agilité à retenu votre attention en Octobre ainsi que le très classique cycle d’amélioration continue Plan/Do/Check/Act.

Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.

plan do check actSi vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?

Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.

FDF est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?  Les histoires plus grosses signifient une meilleure efficacité, non ?  Pas nécessairement.

CertYou est partenaire de DantotsuPM

3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.

Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.

Hexagon est partenaire de DantotsuPM

 

Techniques Agiles : Les objectifs dans Scrum (Scrum Goals)

Agile Techniques: Scrum Goals

https://tcagley.wordpress.com/2019/08/29/agile-techniques-scrum-goals/ par Thomas Cagley.

Guide téléchargeable gratuitement

Le Scrum Guide décrit un objectif de sprint comme “un objectif qui sera atteint dans le Sprint par la mise en œuvre de l’Arriéré de Produit (Product Backlog) et fournit des directions à l’Équipe de Développement sur pourquoi elle construit l’Incrément”. L’objectif de Sprint est un outil pour manager et concentrer les activités de l’équipe. L’équipe utilise son énergie afin de livrer la fonctionnalité exigée pour satisfaire l’objectif.

Comme outil de communication, l’objectif doit être exposé dans la langue du business/métier et indiquer succinctement 2 choses

  1. Pourquoi le travail est fait.
  2. Ce que le résultat accomplira.

En tant que communication, l’objectif de sprint doit parler aux parties prenantes comme aux composantes techniques de l’équipe. Définir de bons Objectifs de Sprint est difficile en partie parce qu’ils sont le reflet d’une négociation entre le propriétaire de produit (Product Owner) et les membres techniques de l’équipe.  Il faut une bonne dose de sueur de part et d’autre pour passer 3 obstacles principaux exigés pour des Objectifs de Sprint efficaces.

CertYou est partenaire de DantotsuPM

Des Objectifs de Sprint Efficaces

  1. Tangibles.  Le résultat de l’atteinte de l’objectif doit être quelque chose qui est substantiel et perceptible.
  2. Mesurables. Le résultat d’un Sprint, par définition, est potentiellement implémentable.  L’impact du résultat devrait être mesurable ou, du moins, possible à valider.
  3. Compréhensibles. La formulation utilisée devrait ÉVITER tout charabia juridique.

Une des utilisations d’un objectif est celle d’un cri de ralliement

Si la formulation de l’objectif ne galvanise pas toutes les parties impliquées il y a un problème. De plus, les équipes utilisent l’Objectif de Sprint afin de savoir quand ils ont terminé et éliminer tout travail qui ne mène pas au résultat agréé.

Planisware est partenaire DantotsuPM

Le guide Scrum 2020 est paru le 18 Novembre

Bonjour, je pense que vous étiez nombreux à l’attendre et il est arrivé à la mi-novembre.

Plusieurs notables évolutions

  1. Moins prescriptif : Scrum est ramené à un cadre minimal suffisant
  2. Objectif de Produit, le « Pourquoi »: Chaque Sprint devrait rapprocher le produit de son objectif global.
  3. Élimination des comportements « proxy » : Une seule équipe Scrum concentrée sur un même objectif de produit avec 3 différents jeux de responsabilités : Product Owner, Scrum Master et développeurs.
  4. Engagements et auto-gestion : Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done. La version 2020 met l’accent sur une Scrum Team autogérée qui choisit qui, comment et sur quoi travailler.
  5. + Lean : En effet, moins de 13 pages que je vous engage à lire et relire…

Écoutez les co-créateurs de Scrum, le Dr Jeff Sutherland et Ken Schwaber parler des mises à jour du Guide Scrum 2020 et de leur importance pour vous

Des pointeurs supplémentaires:

CertYou est partenaire de DantotsuPM

Le saviez-vous: Scrum a déjà 25 ans !

Je ne sais pas depuis combien de temps vous-même utilisez Scrum mais je pense qu’un quart de siècle de vie et d’usages est une étape importante pour cette approche et cet état d’esprit.

Que Scrum signifie-t-il pour vous ?

CertYou est partenaire de DantotsuPM

Quelques pistes pour partager votre expérience :

  • Quand avez-vous rencontré Scrum pour la première fois ?
    • Sur quel projet ?
    • Quel fut le résultat ?
  • En quoi cette approche vous a-t-elle impacté ?
    • Au niveau professionnel ?
    • Au niveau personnel ?
  • Aujourd’hui qu’est-ce que Scrum signifie pour vous ?
Postez vos réponses dans les commentaires: texte, vidéo, images… toutes sont les bienvenues.

Michel.


Ken Schwaber et Jeff Sutherland pour un événement virtuel en live pour célébrer leurs 25 ans (de Scrum) !

Inscrivez-vous rapidement

Le 18 Novembre: Événement gratuit (nombre de places limité)

Inscriptions

3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

Les caractéristiques qui font un propriétaire de produit de qualité sont difficiles à lister, mais voici trois compétences ou attitudes auxquelles donner la priorité dans votre recherche.

3 Elusive Qualities of a Great Product Owner

https://www.agileconnection.com/article/3-elusive-qualities-great-product-owner par John Yorke

Quand il s’agit de diriger le développement d’un produit et de s’assurer de vous construisez ce dont l’utilisateur a réellement besoin, le/la propriétaire de produit est la personne la plus importante pour l’équipe. Il y a juste un problème : un bon product owner peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici trois qualités auxquelles vous devriez donner la priorité dans votre recherche.

Cela peut sembler excessivement simpliste, mais généralement les produits réussissent ou échouent en fonction de l’efficacité du propriétaire de produit dans l’équipe. Cela arrive principalement parce que nous sous-estimons l’importance (et la difficulté) des différents aspects du Product Ownership dans le processus de création de produit.

Le rôle d’un propriétaire de produit couvre tout le spectre, de la découverte à la livraison et plus et donc le choix de la bonne personne pour ce rôle est beaucoup plus important que le coach Agile ou autres membres d’équipe.

la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Cependant, nous avons tendance à penser aux logiciels comme étant des objectifs principalement techniques. Notre focus est trop souvent placé sur la qualité et la capacité des ingénieurs, l’architecture et la conception et nous dépensons un temps disproportionné sur les processus, l’optimisation et l’efficacité. Nous avons tendance à oublier que l’échec le plus commun et le plus répété de tous les produits logiciels (peu importe leur qualité, optimisation et efficacité, ou combien les ingénieurs sont qui les ont construits sont doués) est que si vous construisez le mauvais article, ce sera un échec.

 

Un produit parfaitement conçu mais inutilisé n’est d’aucune valeur.

L’histoire est pleine de grands produits qui ont raté l’objectif. Combien d’applications avez-que vous téléchargées sur votre téléphone que vous avez arrêté d’utiliser après les trente premières secondes ? Sans mentionner les innombrables produits qui échouent à jamais d’atteindre les mains de clients et dont nous n’avons jamais entendu parler.

Les produits de l’informatique interne de l’entreprise sont souvent coupables d’une idée erronée: L’assomption semble être que comme les clients seront forcés d’utiliser le produit, nous ne devons pas vraiment leur demander ce qu’ils veulent ni comment ils l’utiliseront. Aussi, nous finissons souvent par construire de « bons » produits qui ne répondent pas au besoin réel de l’utilisateur.

CertYou est partenaire de DantotsuPM

Considérez cette citation de Peter Drucker : “Il n’y a sûrement rien d’aussi inutile que de faire avec une grande efficacité ce qui ne devrait pas être fait du tout.”

Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.

Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.

1. La capacité à différencier ce qui est nécessaire de ce qui est voulu

Une partie significative du rôle de propriétaire de produit est d’identifier ce qui est nécessaire pour résoudre les problèmes des utilisateurs, répondre à leurs besoins, leur permettre d’être meilleurs dans leur travail, ou maximiser leur amusement ou relaxation. Le rôle consiste avant tout en la compréhension du problème et la création d’une vision de comment ce problème pourrait être résolu. Pas la solution technique, mais le vrai besoin.

La raison pour laquelle cette compétence est si complexe est que les utilisateurs savent rarement de quoi ils ont besoin. Typiquement la vision d’un utilisateur est contrainte par ce qu’il fait actuellement. En conséquence, beaucoup de produits reviennent à retravailler un système papier existant ou une vieille approche.

Un faible propriétaire de produit donne aux clients ce qu’ils veulent ou ce qu’ils ont demandé mais un bon propriétaire de produit écoute et observe et peut mélanger veut et doit pour résoudre le problème du client et lui donner ce dont il a vraiment besoin.

Ce point nous mène à une citation intéressante par Henry Ford : “si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides.”

Nous voyons souvent des arriérés de produits pleins d’histoires utilisateur qui sont vraiment juste des demandes client non filtrées. Il est plus facile de faire ce que le client demande que de trouver ce qui est en réalité nécessaire. Car cela exige typiquement de l’expérimentation, des retours utilisateurs, des conversations et de l’observation.

Cela peut aussi se produire quand les managers de département décident ce dont leur équipe a besoin ou veut sans impliquer les membres dans la discussion. Mais un bon propriétaire de produit passera du temps avec les utilisateurs du produit et verra comment ils l’utilisent. Un propriétaire de produit avec créativité, initiative et vision pour créer un grand produit vaut son pesant d’or.

2. La compréhension de ce qui exigée pour créer une application réussie

Peut-être à cause de l’accent placé sur le point numéro un, les sociétés choisissent souvent quelqu’un du côté business ou métier pour devenir le propriétaire de produit, car on voit leur connaissance du business comme primordiale et, dans des nombreux cas, la seule et unique qualification pour le rôle. Et pire encore, on leur demande souvent de tenir ce rôle en plus de leur travail habituel.

Cependant, les excellents propriétaires de produit comprennent quoi construire, mais sont aussi familiers avec le processus de développement. Ils comprennent les flux, les implications de la dette technique, l’automatisation et les tests. Ils comprennent aussi à quel point il est crucial de mettre le logiciel entre les mains d’utilisateurs aussitôt que possible.

En général, des propriétaires de produit « business » manquent souvent de cette connaissance et de cette expérience et ils suivront par erreur le désir d’un produit entièrement fonctionnel plutôt que d’apprécier la valeur de retours rapides. Beaucoup essaient d’inclure chaque fonction imaginable plutôt que de travailler vers un jeu de fonctions minimal pour obtenir des retours et tirer de la valeur le plus tôt possible.

Que préfèreriez-vous avoir ? Un propriétaire de produit expérimenté avec zéro connaissance business, ou un expert business avec zéro expérience de livraison de logiciel ? Avant que vous ne répondiez, considériez ceci : la connaissance business peut être obtenue par une discussion efficace, l’observation et les retours. Cependant, la compréhension d’un bon cycle de développement logiciel agile est beaucoup plus difficile à apprendre et il n’y a rien qui remplace l’expérience.

Typiquement les meilleurs produits résultent d’expériences, de tests et de retours, avec une volonté à être flexibles dans les réponses. Les propriétaires de produit posent des priorités et interprètent la vision, donc ils ont plus d’influence sur la création de produit que qui que ce soit d’autre. Leurs choix de priorités peut profondément impacter la valeur et la qualité du produit. S’ils manquent de compréhension sur l’importance des tests, des retours utilisateurs et des bons principes de développement logiciel, ils peuvent entrer en conflit et semer le désaccord dans une équipe.

Hexagon est partenaire de DantotsuPM

3. Une communication efficace avec les parties prenantes tant techniques que business

Pour terminer, il y a un énorme besoin de communication efficace. L’importance ne peut pas en être exagérée.

Les excellents propriétaires de produit écoutent, observent, explorent et réfléchissent. Ils demandent des retours, lisent entre les lignes et observent le langage corporel. Quand il s’agit de comprendre l’utilisateur, ils portent une grande attention aux détails et recherchent attentivement des points de douleur et de satisfaction. Ils cherchent les meilleures façons de servir leurs utilisateurs.

La plupart d’entre nous pensent à la communication comme à une conversation, mais pour un propriétaire de produit, l’observation et l’écoute sont aussi très importantes. Avoir de l’empathie avec l’utilisateur et le client est critique. Il est impératif de comprendre leur domaine et d’utiliser leur vocabulaire pour communiquer. Si vous ne comprenez pas certains termes, il est essentiel de développer une attitude attentive et de poser des questions pour montrer votre intérêt, votre envie d’apprendre et votre engagement.

Un grand propriétaire de produit apprend à dire non avec respect et d’une manière qui indique qu’il comprend ce qui est demandé. Grâce à cela, on ne devrait pas voir un bon propriétaire de produit comme un obstacle ou une barrière, mais un guide vers de bonnes décisions. Le mot « Non » devrait être délivré d’une façon qui laisse le client confiant que cette décision est juste, même si ce n’est pas ce qui a été initialement voulu et que le propriétaire de produit livrera le meilleur produit en fonction de tous les paramètres.

Au contraire, si le propriétaire de produit choisit de dire oui, il devrait être capable d’en transmettre les implications. Les propriétaires de produit devraient avoir un certain nombre d’outils qui peuvent aider les gens à comprendre leurs décisions.

Le propriétaire de produit doit aussi communiquer avec l’équipe de développement et doit comprendre des termes techniques de développement pour qu’ils puissent avoir une pleine compréhension de la mise en œuvre technique, même s’ils n’ont pas d’autorité sur comment les choses sont faites. Autrement dit, ils devraient avoir un fort intérêt dans la compréhension du processus.

Ils doivent aussi être capables de communiquer des besoins business et des termes métier d’une façon qui donne du sens à l’équipe de développement. Être respectés et compris tant par le business que l’équipe technique est un exploit majeur et comme nous le savons, tout groupe parle dans le jargon que seuls ses membres comprennent. Ces signes verbaux que l’on doit expliquer à un étranger peu familier peuvent démoraliser l’équipe. Il est important de ne pas sous-estimer cette capacité.

Les propriétaires de produit ont aussi besoin de créativité pour communiquer des idées de design, ou, si les idées viennent d’autres, la capacité de comprendre cette créativité et de la transmettre aux équipes business et techniques. Il en va de même pour les parties prenantes principales (mis à part les utilisateurs). Ce groupe finance généralement le produit et ils veulent voir la progression et un bon management de leur investissement, donc ils peuvent demander des prévisions et insister même sur des engagements fermes.

Et si un produit doit être vendu, il est probable que le propriétaire de produit devra être impliqué avec les ventes et le marketing, ce qui amène tout un train d’autres compétences et de problèmes de communication, y compris la compréhension des implications sur le marché.

En prenant tout ceci en considération, nous avons maintenant chargé notre propriétaire de produit du besoin de communiquer avec les gens expérimentés qui prennent des décisions financières, d’exprimer les risques et les prévisions de façon concise, mais significative et transparente, informative et confiante. Un propriétaire de produit devrait tenir bon sur sa position et parler vrai face aux autorités et au pouvoir.

Bref, un grand propriétaire de produit est un maître communicateur, a un désir insatiable de connaissance et cherche toujours à comprendre et à être compris.

Recherchez et appréciez les bons Propriétaires de Produit

Le jeu de compétences d’un bon propriétaire de produit est large et diversifié, cependant les bons font paraître cela facile. Si vous avez un état d’esprit de propriétaire de produit, il est probable que vous avez déjà de bonnes compétences de communication et que vous aimez en apprendre davantage dans de nombreux domaines.

Il est aussi probable que vous êtes le genre de personne qui donne tout pour livrer un produit et se délecte des réactions, aime la flexibilité et le changement et ne se démotive pas à la pensée de devoir refaire quelque chose pour l’améliorer.

La résolution de problèmes est un challenge et être capable de voir au-delà de l’évident, d’aller chercher l’information chez les utilisateurs et présenter ensuite quelque chose de grand peut être une joie. Cela ne signifie pas, cependant, que ce n’est pas incroyablement difficile, accablant de temps en temps, tristement inapprécié et peut-être sous-payé. Mais un grand propriétaire de produit réussira malgré ces points douloureux.

Le propriétaire de produit est la clé de voute d’un grand produit et nous devrions les rechercher et les utiliser convenablement. Vous serez stupéfié de ce qui peut être réalisé avec la bonne personne dans ce rôle.

FDF est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?

The Magic of Small User Stories

https://www.agilealliance.org/the-magic-of-small-user-stories/ par Dwight Kingdon

J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?  Les histoires plus grosses signifient une meilleure efficacité, non ?  Pas nécessairement.

Pourquoi des histoires plus courtes ?

  • Une petite de dose satisfaction à chaque histoire complétée

    Focus : Des histoires courtes nous focalisent et nous aident à voir que la fin n’est pas trop éloignée. Il est fréquent de se sentir écrasé par les détails quand nous travaillons sur de longues histoires.  De brèves histoires génèrent aussi une satisfaction de l’équipe plus élevée; les personnes reçoivent une petite dose de dopamine à chaque fois qu’elles finissent quelque chose.

  • Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le Daily Stand-Up.  Le réalisé est facile à suivre quand nous voyons une série de courtes histoires achevées; il est plus difficile d’évaluer et de visualiser le réel progrès sur une grande histoire chaque jour.
  • Relisez ce billet sur pourquoi Fibonacci

    Prévisibilité : Des histoires courtes ont tendance à aboutir vélocité plus précise et juste, ce qui réduit la variabilité et améliore la prévisibilité.  Des évaluations relatives de points d’histoire en utilisant la séquence de Fibonacci sont par définition de moins en moins précises pour de plus grandes histoires – voir “le cône d’incertitude”.  Ainsi, une histoire 13 ou à 20 points est probablement beaucoup moins prévisible que plusieurs histoires à 2, 3, ou 5 points.

  • Flexibilité : Des histoires courtes fournissent .  Elles fournissent davantage de flexibilité pour nous adapter comme nous apprenons.  Quand les circonstances changent ou que certaines histoires deviennent sans utilité, il y a moins de perte dans la réorganisation ou l’élimination d’une courte histoire.
Relisez ce billet
  • Livraison : Des histoires courtes permettent aux équipes de test de commencer à évaluer plus tôt dans le sprint et de travailler sur de plus petites portions de code.
  • Risque Réduit : Des histoires volumineuses augmentent le risque que l’équipe ne livre rien à la fin du sprint qui soit 100 % fait (Done).  La capacité de l’équipe ressemble à un entonnoir.  Quand nous essayons de forcer un grand objet (de grandes histoires) à y passer, l’entonnoir se bouche.  Par exemple, un développeur travaillant sur une grande histoire peut aussi être le seul avec le jeu de compétences nécessaires pour compléter une autre histoire critique.

Comment puis-je créer des histoires plus courtes ?

Vous trouverez des tas de bons articles sur la décomposition d’histoires d’utilisateur sur Google.  Néanmoins, voici une poignée de questions que j’ai trouvé utiles pour déterminer comment créer des histoires plus courtes :

  • 80/20
    Vidéo explicative sur Pareto

    S’il y a plusieurs résultats dans une unique histoire utilisateur, sont-ils tous nécessaires tout de suite ? Y-a-t-il un découpage 80/20 qui fournirait la majeure partie de la valeur ?  Pouvez-vous développer ces 20 % dans une autre histoire différente ?

  • Avez-vous des règles métier multiples ou plusieurs personas dans l’histoire utilisateur ? Ces règles métier peuvent-elles être construites séparément, ou les différents personas traités dans des histoires séparées ?  Des règles métier plus simples peuvent-elles suffire pour le moment pour faire marcher la solution ?
  • Est-ce que le parcours optimal peut être codé en premier sans toutes les exceptions ?  Ces exceptions peuvent souvent être relogées dans des histoires complémentaires.
  • Y-a-t-il de multiples plates-formes ou plusieurs interfaces utilisateur associées à l’histoire utilisateur ? Pouvons-nous les développer une par une ?
  • Des opérations multiples sont-elles contenues dans l’histoire utilisateur c’est-à-dire  Créer, mettre à jour, supprimer une donnée? Pouvons-nous développer une opération à la fois ?
  • Quels scénarios de test s’appliquent ? Certains scénarios sont-ils complexes et pas très critiques ?  Une première itération plus simple peut-elle être développée pour valider le design ?
  • La plupart de la complexité de l’histoire vient-elle d’exigences non-fonctionnelles comme la sécurité ou la performance ?  Si c’est le cas, l’histoire peut-elle être découpée pour d’abord faire le travail sur la fonctionnalité, puis modifiée plus tard pour satisfaire ces exigences non-fonctionnelles ?

Combien courte est « courte » ?  Quelle est la bonne taille ?

Relisez ce billet sur la méthode INVEST

Ce sont des questions très subjectives et elles dépendent de plusieurs facteurs dont la capacité de l’équipe, la durée de sprint et autres.  Un bon point de départ pour déterminer la taille idéale de l’histoire doit utiliser l’acronyme I.N.V.E.S.T.  Si vous êtes peu familiers avec cette approche, cherchez simplement “agile invest” sur votre navigateur internet pour en apprendre davantage.  Une histoire doit délivrer la valeur.  Livrer une histoire qui a peu de bénéfices perceptibles juste pour la garder petite n’a probablement aucun sens.  Au final, les histoires utilisateur plus courtes sont d’habitude meilleures que de plus longues.  Mais, le bon sens s’applique pour vous assurer qu’une histoire utilisateur peut livrer une réelle valeur et peut aussi être achevé en un unique sprint.

CertYou est partenaire de DantotsuPM

Disciplined Agile : Êtes-vous curieux d’en apprendre davantage ?

Si vous avez entendu parler de Disciplined Agile et que vous voulez en apprendre davantage…

L’équipe Disciplined Agile du PMI France se propose de vous accompagner dans cet apprentissage en lançant le Special Interest Group (SIG) Disciplined Agile.

Relisez ce billet sur les certifications Agile du PMI
A qui s’adresse le SIG ? Tous les membres du chapitre PMI France sont les bienvenu.e.s.

Comment participer au SIG ?

Répondez au questionnaire d’inscription au SIG Disciplined Agile PMI-France afin de vous inscrire.

QRP est partenaire de DantotsuPM

Comment ça marche ?

  • Les activités du SIG sont concentrées sur un forum dans un environnement technique encore en cours de définition.
  • Ce forum permettra aux membres du SIG d’échanger librement dans le cadre d‘une charte de bonne conduite (qu’en bons agilistes nous définirons ensemble)
  • Différentes activités seront proposées dont la 1ère sera un cercle d’étude.

Quand ? Dès novembre 2020

Tous les détails sur le site PMI France
CertYou est partenaire de DantotsuPM