Étiquette : product owner

« Libérez l’agilité organisationnelle ! Les indicateurs clés que tout leader devrait mesurer. » Sam Adesoga.

Le par mopertodans leadershipLaisser un commentaire

Explorez 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation.

Unlocking Organisational Agility: Key product metrics every business leader should measure par Sam Adesoga

https://www.valuehut.co/blog/unlocking-organisational-agility-key-product-metrics-every-business-leader

 Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide.  La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.

Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.

#1 – Fréquence de livraison (de sortie)

Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.

L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.

Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :

  • Investissement dans les capacités d’intégration et de déploiement continus.
  • Tests fonctionnels et non fonctionnels automatisés.
  • Amélioration des capacités de management de produits, y compris la capture et l’analyse des commentaires des utilisateurs.
  • Créer des équipes inter-fonctionnelles dans le cadre des efforts de conception de l’organisation.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

#2 – Incidents par période

Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.

Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.

Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :

  • Capturez la dette technique en tant qu’éléments de premier ordre de l’arriéré de produit.
  • Augmentez les tests automatisés autour des fonctionnalités sujettes aux incidents.
  • Obtenez l’engagement de l’équipe produit à réduire la dette technique sur une période donnée.
  • Améliorez les capacités d’analyse des logs des utilisateurs pour repérer les problèmes potentiels.

#3 – Délai d’exécution

Le développement de produit est complexe. Complexe implique qu’il n’y a pas de relation directe entre la cause et l’action [Lire : Modèle Cynéfin]. En termes plus simples, il n’y a aucune garantie que les hypothèses que l’équipe produit fera lors de la construction du produit correspondront à la réalité. Par conséquent, plus tôt une organisation peut mettre en œuvre ses idées et mettre le produit entre les mains d’un utilisateur, plus tôt la valeur supposée du produit peut être validée.

La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.

Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.

Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.

Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.

Les facteurs qui améliorent les délais sont les suivants :

  • Réduire et, éventuellement, éliminer les temps d’attente dans le système.
  • Contribuer à limiter les travaux en cours.
  • Automatisation des tests et des déploiements.

#4 – Indice de satisfaction des employés

Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas

tristeLes employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.

Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :

  • Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.
  • Le leader s’est engagé à financer des changements d’infrastructure afin de réduire la durée des cycles et d’augmenter la fréquence des livraisons.
  • Augmentation de la sécurité psychologique au sein de l’équipe.

Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.

#5 – Satisfaction du client

Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.

Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.

Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS) et le taux d’attrition des clients.

L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.

Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.

Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

Toute augmentation des travaux en cours d’exécution dans votre projet Agile augmente automatiquement les délais !

Le par mopertodans agile, experience sharing1 commentaire

Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?

La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.

Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.

En 1961, Little a énoncé son théorème :

Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.

Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.

De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).

Cette formule est souvent exprimée ainsi :

WIP = T x LT

ou encore

LT = WIP / T

Toute augmentation des travaux en cours WIP augmente automatiquement les délais.

Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.

De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

La loi de Little dans le cadre du management de projet

Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.

Cela correspond comme je l’ai mentionné précédemment aux objectifs recherchés par le management des flux avec Kanban dans les projets Agiles.

Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.

Prenez un exemple :

  • Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
  • Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.

Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.

Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.

Bien sûr, tout n’est pas si linéaire…

En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…

Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.

Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.

Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.

Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.

Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.

Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, le switching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.

En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.

Et pour le management de Portefeuille de Projets (PPM) ?

Project Portfolio Management dimensionsLa loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.

Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !

Plus spécifiquement sur les projets Agiles

Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.

C’est en Agile en grande partie la responsabilité du Product Owner.

Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !

En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.

En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.

Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?

J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.

Quelle est votre expérience de cette Loi de Little ?

Y-a-t-il des avantages à avoir un Product Owner sur un projet CRM ? par Mohamed Michael Kazak

Le par mopertodans agile, experience sharingLaisser un commentaire

La réponse courte est OUI !

Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.

Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.

Comprendre les besoins et les exigences de l’entreprise

Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.

Guider le processus de développement

Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.

Trouver l’équilibre entre les besoins de l’entreprise et la convivialité

Trouver le bon équilibre entre les besoins des uns et des autres.

L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.

Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.

Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.

Communiquer avec les parties prenantes

En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.

Assurer le succès du lancement et de l’adoption

Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.

En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.

Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.

Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.

Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.

Mohamed Michael Kazak

 

Mohamed Michael Kazak

Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.

Précédents billets de Mohamed Michael Kazak

Discussions suite au billet « Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? » de Mohamed Michael Kazak

Le par mopertodans agile, best practicesLaisser un commentaire

« Merci pour votre commentaire Serge Amon. Vous soulignez un défi crucial dans la gestion Agile des projets CRM : L’engagement profond et la disponibilité des équipes métier, souvent compliqués par un manque d’acculturation au mode projet Agile. »

Réponse et suite au billet « Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? » de Mohamed Michael Kazak

Pour y faire face, voici quelques idées

Planification anticipée : Fixer les ateliers environ 6 semaines à l’avance améliore la participation et la préparation.

Objectifs clairs : Définir des buts précis pour chaque atelier afin de garantir une collaboration efficace et pertinente.

Implication dès le départ et communication régulière : Cruciales pour aligner les attentes et maintenir l’engagement.

Flexibilité et formation : Adapter les horaires pour les parties prenantes et les éduquer sur l’Agile pour faciliter leur adhésion.

Brièveté et concentration : La réduction de la durée des ateliers à 1h30 est une mesure parmi d’autres, visant à une efficacité maximale.

L’engagement et l’adaptation culturelle nécessitent une approche multi-facettes et un engagement réel de toutes les parties.

Vos réflexions enrichissent cette discussion, et j’aimerais beaucoup entendre d’autres idées ou stratégies que vous pourriez avoir.

 

Comment maîtriser l’art de comprendre les besoins de l’entreprise dans un projet Agile de gestion de la relation client (CRM) ? par Mohamed Michael Kazak

Le par mopertodans agileLaisser un commentaire

La réponse courte est qu’un Product Owner ne devrait jamais improviser dans ses activités.

https://www.linkedin.com/pulse/mastering-art-understanding-business-needs-salesforce-kazak/

Permettez-moi de partager avec vous le processus que je suis pour comprendre les besoins des entreprises et explorons les différents outils et techniques que j’utilise pour y parvenir.

N’oubliez pas qu’il s’agit surtout d’art dans un cadre de travail défini.

Interrogez les principales parties prenantes

La première étape pour comprendre les besoins et les exigences de l’entreprise consiste à interroger les principales parties prenantes. Il peut s’agir de chefs de service, d’utilisateurs finaux et de cadres exécutifs.

L’objectif de ces entretiens est de comprendre les processus métier, les flux de travail et les points faibles que votre projet Agile va résoudre.

Le Product Owner doit préparer une liste de questions à l’avance pour guider la discussion et s’assurer que tous les sujets pertinents sont couverts.

Faites vos devoirs

À la suite des entretiens avec les parties prenantes, une chasse aux informations supplémentaires commence. L’une des tâches clés du Product Owner est de bien connaître la situation actuelle et d’identifier les domaines à améliorer ou à optimiser.

Voici quelques-uns des éléments que le Product Owner examinera :

  • Cartes ou diagrammes des processus métier actuels
  • Manuels ou guides d’utilisation existants
  • Résultats de précédents sondages (ou lancement d’un nouveau)
  • Commentaires des utilisateurs ou tickets de demandes d’assistance
  • Données historiques ou rapports sur l’utilisation du système actuel et performances des processus

En examinant ces documents et ces données, et en recueillant les informations des parties prenantes, le Product Owner peut mieux comprendre l’état actuel des processus métier et identifier les domaines à améliorer ou à optimiser. Cela permettra au Product Owner de travailler plus efficacement dans la phase d’atelier et plus tard avec l’équipe de développement pour concevoir et mettre en œuvre de manière Agile des solutions qui répondent aux besoins spécifiques de l’entreprise.

Animez des ateliers

Une fois que les principales parties prenantes ont été interrogées et que le Product Owner s’est formé, il ou elle peut animer des ateliers pour approfondir les exigences. Les ateliers peuvent être utilisés pour identifier les lacunes dans les processus métier actuels, hiérarchiser les caractéristiques et les fonctionnalités nécessaires, et définir les histoires utilisateurs.

Voici quelques-unes des meilleures pratiques pour assurer le succès des ateliers :

  • Préparez-vous et soyez ouverts d’esprit,
  • Posez des questions ouvertes,
  • Les ateliers ne doivent pas durer plus de 1h30,
  • Permettez aux participants de discuter des désaccords, mais rappelez-leur aussi ce qu’ils ont en commun.

Voici une liste d’ateliers qui peuvent être réalisés avec une proposition d’ordre du jour. Veuillez noter que ces séances peuvent être ajustées en fonction des besoins et des objectifs spécifiques du projet, et que l’ordre du jour peut être affiné en fonction des retours des principaux intervenants.

Atelier 1 : Introduction et examen des processus métiers et business

L’objectif de cet atelier est de cartographier les processus métier et les flux de travail de l’organisation, et d’identifier les opportunités d’automatisation et d’optimisation à l’aide de votre nouvelle solution. Cela permettra de s’assurer que le nouveau système est adapté aux besoins spécifiques de l’organisation et qu’il apporte une réelle valeur ajoutée. Bien que le Product Owner ait recueilli pas mal d’informations à partir d’entretiens et de données existantes, la réalité est souvent différente de ce qui est sur papier.

  • Accueil et présentations (10 min)
  • But et objectifs de l’atelier (10 min)
  • Revue des processus métiers actuels (30 min)
  • Identification des principaux défis et points faibles de l’entreprise (20 min)
  • Discussion sur les améliorations potentielles des processus existants (20 min)
Atelier 2 : Cartographie du parcours utilisateur

L’objectif de cet atelier est de comprendre les besoins et les difficultés des utilisateurs, et de cartographier leur parcours tout au long des processus de l’organisation. Cela permettra de s’assurer que le nouveau système est conçu de manière intuitive et conviviale, améliorant ainsi l’adoption et l’efficacité par les utilisateurs.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Identification des personas d’utilisateurs clés (20 min)
  • Cartographie des parcours utilisateurs pour chaque persona (40 min)
  • Discussion sur les points faibles et les possibilités d’amélioration dans chaque parcours (20 min)
Atelier 3 : Hiérarchisation et définition des fonctionnalités

Cet atelier consiste à définir et à hiérarchiser les fonctionnalités et les exigences nécessaires à la nouvelle solution, en fonction de l’évaluation de l’état actuel, de la cartographie des processus métier et des exercices de cartographie du parcours utilisateur. L’objectif est de définir le Produit Minimum Viable (MVP) qui peut être livré aux utilisateurs le plus rapidement possible tout en répondant à leurs besoins. Cela permettra de s’assurer que le système est conçu et construit de manière à s’aligner sur les besoins de l’organisation et à apporter une réelle valeur ajoutée.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Hiérarchisation des fonctionnalités en fonction de la valeur business et des besoins des utilisateurs (20 min)
  • Définition des fonctionnalités clés et des exigences pour chaque fonctionnalité prioritaire (40 min)
  • Discussion sur les concessions et compromis potentiels (20 min)
Atelier 4 : Exigences techniques et récapitulatif
Les problèmes complexes ont souvent de multiples solutions et chemins pour les atteindre.

Cet atelier se concentre sur la définition des exigences techniques du produit en fonction des fonctionnalités prioritaires et des contraintes identifiées. L’objectif est d’identifier les défis techniques potentiels et les solutions qui doivent être prises en compte au cours du processus de développement. Les contraintes, telles que le budget, l’échéancier et la disponibilité des ressources, doivent être discutées, ainsi que les solutions potentielles pour y remédier. L’atelier se termine par un résumé du processus de collecte des exigences et un plan pour aller de l’avant avec le développement.

  • Accueil et présentations (10 min)
  • Rappel des principaux points à retenir de l’atelier précédent (10 min)
  • Identification des exigences ou contraintes techniques (30 min)
  • Discussion sur les solutions potentielles pour répondre aux contraintes techniques (30 min)
  • Récapitulatif des principaux points à retenir de la série d’ateliers (10 min)
  • Mesures à prendre et prochaines étapes (20 min)

Documentez les exigences

Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)

Une fois les ateliers terminés, le Product Owner doit documenter les exigences. Cela inclut la création d’histoires utilisateur, la définition de critères d’acceptation et la création d’un arriéré de produit (product backlog). Le Product Owner doit travailler avec les parties prenantes pour s’assurer que les exigences sont exactes, complètes et alignées sur les besoins de l’entreprise.

Hiérarchisez les exigences

Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.

Affinez les exigences (Précisez les besoins)

Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.

Anticipez les difficultés auxquelles le product owner sera confronté

Imaginez une entreprise avec plusieurs divisions, chacune avec son propre processus de vente unique. L’équipe de vente de la division A a besoin d’un ensemble d’informations différent de celui de l’équipe de vente de la division B pour collecter un ensemble d’informations différent de celui de l’équipe de vente de la division B. Cependant, l’entreprise souhaite maintenir une instance de votre solution unifiée à des fins de reporting et d’analyse.

Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.

En tirant parti de cette flexibilité, le Product Owner peut combler efficacement le fossé entre les différents processus métier de chaque division et s’assurer que la solution globale est optimisée pour la réussite dans l’ensemble de l’entreprise.

La compréhension des besoins et des exigences de l’entreprise est essentielle à la réussite de votre projet quel qu’il soit.

Le Product Owner doit interviewer les principales parties prenantes, organiser des ateliers, documenter les exigences, hiérarchiser celles-ci, et examiner et affiner les besoins tout au long du processus de développement.

En suivant ces étapes, le Product Owner peut s’assurer que le système répond aux besoins de l’entreprise et des utilisateurs finaux et qu’il apporte une réelle valeur ajoutée.

Mohamed Michael Kazak

Mohamed Michael Kazak

Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.

CertYou est partenaire de DantotsuPM, allez voir les formations et certifications Agile dont celles de Product Owner

Dans le développement de produit : Le produit est la variable.

Le par mopertodans experience sharing, outils et méthodesLaisser un commentaire

Avec le passage à DevOps, les systèmes que nous construisons ont acquis deux nouvelles qualités importantes : Ils ne finissent jamais et ils fournissent de continuelles rétroactions et  opportunités d’apprendre.

The Product is the Variable par Jeff Gothelf

https://jeffgothelf.com/blog/the-product-is-the-variable/

Il m’est apparu récemment qu’il y a une transformation radicale dans notre conversation sur le développement de produits numériques en raison du changement (certes lent) mais inévitable vers le management des résultats. Pendant des décennies, la composante « fixe » de nos conversations sur les produits était le produit lui-même. Bien sûr, nous nous sommes peut-être déportés vers les délais, la portée et/ou les choix de conception, mais la question de « allons-nous le livrer ? » n’a jamais été mise en doute. Le produit allait certainement arriver.

Le déploiement du produit n’est plus certain

Avec le passage aux systèmes de déploiement continu, de test et d’intégration continus (alias DevOps), les systèmes que nous construisons ont acquis deux nouvelles qualités importantes :

  1. Ils ne sont jamais finis – Nous travaillons sur nos produits, aujourd’hui, « pour toujours ». Il n’y a pas de date de fin fixe pour les fonctionnalités que nous construisons. Cela semble étrange ? Demandez-vous : « Quand Netflix sera-t-elle terminée ? » Remplacez « Netflix » par n’importe quelle autre entreprise moderne et il devient clair que nos produits et services vivent pour toujours. Il n’y a pas de date de fin explicite. À un moment donné, nous décidons qu’ils ne fournissent plus assez de valeur ou que l’investissement nécessaire pour en extraire plus de valeur n’en vaut pas la peine et nous passons à autre chose. D’ici là, nous devons maintenir et optimiser ces systèmes en permanence.
  2. Ils fournissent une rétroaction continue et une opportunité d’apprentissage – Parce que ces systèmes sont toujours en vol, offrant de la valeur (ou non) et fournissant un service aux clients, nous apprenons continuellement à quel point ils fonctionnent. Nous avons maintenant une opportunité incroyable de déterminer où concentrer au mieux nos efforts pour améliorer continuellement ces systèmes pour nos clients.
Apporter la plus grande valeur aux clients, aussi rapidement que possible.

Ces qualités nous obligent à considérer une mesure de la valeur différente de celle du passé. Nous n’avons plus besoin de nous concentrer sur le fait de savoir si nous avons livré ou non une fonctionnalité spécifique. Au lieu de cela, nous nous concentrons sur ce que nos clients font dans le système. Réussissent-ils ? L’utilisent-ils d’une manière qui leur profite ? Font-ils ce à quoi nous nous attendions ? Autre chose ? Notre obsession n’est plus de savoir si une capacité spécifique a été déployée ou non, mais plutôt de savoir si le système offre de la valeur. Une volonté de « simplement diffuser des fonctionnalités » n’a plus de sens dans ce nouveau contexte.

Le produit est la variable

La nature moderne des logiciels se concentre sur le déploiement de la plus petite quantité de code qui offre la plus grande quantité de valeur. Pourquoi ? Parce que nous devons vivre avec ce code pour toujours. Notre nouvelle mesure du succès est le comportement des clients (ou les résultats). Les comportements et les changements dans ces comportements que nous voulons voir chez nos clients sont nos nouvelles mesures du succès. La façon dont nous réalisons ces changements de comportement devient la variable. Le produit est la variable.

Il existe une combinaison infinie de code, de conception, de proposition de valeur et de modèle commercial qui peut apporter les changements de comportement souhaités. Nous mélangeons, associons et expérimentons différentes façons de rendre notre offre plus précieuse pour nos clients. L’objectif fixé est un changement dans le comportement de nos clients. Nous continuons à ajuster et (espérons-le) à améliorer le produit jusqu’à ce que nous atteignions le niveau souhaité de changement de comportement.

Cela nécessite un nouvel état d’esprit pour le développement de produits

Accepter ce changement dans la façon dont nous manageons nos équipes et nos organisations ne sera pas facile. C’est un profond changement de mentalité. Il est facile de considérer le produit comme l’objectif. Nous pouvons clairement écrire ce que nous croyons qu’il devrait faire, le concevoir pour le faire et le livrer. Malheureusement, cela ne garantit pas notre succès. Cela ne garantit que le déploiement du code (et la dette technique subséquente). La variabilité des produits peut effrayer les parties prenantes. « Qu’est-ce qu’on construit ? », demanderont-ils. En fin de compte, nous devons changer cette question en : « Comment tendons-nous vers les changements de comportement souhaités ? » Cela prendra du temps, mais c’est inévitable. Nos socles technologiques modernes l’exigent.

Vos clients détestent les MVPs (Minimum Viable Product), produisez plutôt un SLC (Simple, Lovable and Complete product).

Le par mopertodans agileLaisser un commentaire

J’ai trouvé ce billet très vrai par rapport à mon vécu personnel sur des projets Agiles qui se sont tellement concentrés sur produire un « Minimum » MVP que leurs premiers livrables n’étaient que très rarement utilisables / « Viables » en situation réelle.

Extraits du billet de  Jason Cohen: Your customers hate MVPs. Make a SLC instead.

Vos clients détestent les MVPs. Faites plutôt un SLC.

[…]

Les équipes produit ont répété le mantra du MVP (Minimum Viable Product) depuis toute une décennie sans réévaluer si c’est réellement la bonne façon de maximiser l’apprentissage tout en satisfaisant le client.

Eh bien, ce n’est pas le meilleur système !

Cette approche MVP est égoïste et fait mal aux clients.

[…]

La motivation qui dirige le MVP est toujours valable :

  1. Construisez quelque chose de petit, parce que les petites choses sont rapides et peu coûteuses à tester.
  2. Mettez-la rapidement sur le marché, car le véritable apprentissage ne se produit que lorsque de vrais clients utilisent un vrai produit.
  3. Jetez-la ou changez complètement de direction s’il s’agit d’un échec, ou investissez davantage s’il s’agit d’un semis avec du potentiel.

Les MVPs sont parfaits pour les startups et les équipes produit car ils maximisent le plus rapidement possible ce que l’on appelle « l’apprentissage validé ». Et, bien que  les entretiens avec les clients soient utiles, vous apprenez de nouvelles choses lorsqu’un client utilise réellement le produit. Mais les MVPs sont un acte égoïste.

Le problème est que les clients détestent les MVPs.

Les startups sont encouragées par le célèbre Reid Hoffman à « lancer le produit assez tôt pour que vous soyez embarrassé par votre version V1.0. ». Mais aucun client ne veut utiliser un produit inachevé qui embarrasse ses créateurs. Les clients veulent des produits géniaux qu’ils peuvent utiliser immédiatement.

Les MVPs sont trop M et rarement V.

Les clients le voient et détestent cela. C’est peut-être génial pour l’équipe produit, mais c’est mauvais pour les clients. Et en fin de compte, ce qui est mauvais pour les clients est mauvais pour l’entreprise.

[…]

Soyez « Slick » (habile et astucieux) !

À partir de ce raisonnement, il y a des années, j’ai nommé ce que je pense être la bonne alternative au MVP : Simple, Lovable/Aimable et Complet (SLC). Nous le prononçons « Slick ». Comme dans : « Quelle est la version (habile et astucieuse) ‘Slick’ de votre idée ? ».

Un autre avantage de SLC devient évident lorsque vous considérez la prochaine version du produit.

Un produit SLC ne nécessite pas de développement continu pour ajouter de la valeur. Il est possible que la V1 évolue pendant des années en une V4, mais vous avez également la possibilité de ne pas investir davantage dans le produit, tout en ajoutant de la valeur. Un MVP qui ne recevra jamais d’investissement supplémentaire n’est qu’un mauvais produit. Un SLC qui n’obtient jamais d’investissement supplémentaire est un bon produit, même s’il est modeste.

Henrik Kniberg, un coach agile et produit de longue date pour Spotify, a créé l’illustration populaire ci-dessus pour donner un exemple à suivre aux équipes produit lorsqu’elles envisagent de livrer un produit minimum viable, ou MVP, à leurs clients.

Une planche à roulettes est un produit SLC. C’est plus rapide que la marche, c’est simple, beaucoup de gens l’adorent, et c’est un produit complet qui n’a pas besoin d’ajouts pour être amusant ou pratique. En même temps, vous pouvez faire évoluer le skateboard en ajoutant une potence et un guidon, pour créer une trottinette (seulement un peu moins simple, et certainement appréciable et complet). Ensuite, vous pouvez faire grandir les roues, ajouter un siège et des pédales, et vous avez un vélo. Encore une fois, moins simple, mais vous avez maintenant un produit avec des avantages massifs de vitesse, de distance et d’efficacité énergétique…

[…]

Avec SLC, les résultats sont meilleurs et vos options pour les prochaines étapes sont meilleures.

Si le SLC échoue, ce n’est pas grave : C’est une expérience ratée. Les SLCs et les MVPs atteindront parfois ce résultat parce que le but est d’ expérimenter. Mais si un SLC réussit, vous avez déjà apporté une valeur réelle aux clients et vous avez plusieurs futurs possibles à votre disposition, dont aucun n’est urgent. Vous pourriez construire une V2, et parce que vous générez déjà de la valeur, vous avez plus de temps pour décider à quoi elle devrait ressembler. Vous pouvez même interroger les clients existants pour déterminer exactement ce que la V2 devrait impliquer, au lieu d’un groupe d’alpha-testeurs qui veulent juste savoir « Quand allez-vous réparer cette chose qui ne fonctionne pas ? »

Ou, vous pouvez décider de ne plus travailler dessus. Tous les produits ne doivent pas nécessairement devenir complexes. Tous les produits n’ont pas besoin de nouvelles versions majeures tous les deux trimestres.

Certaines choses peuvent juste rester Simples, aimables/Lovable et Complètes.

Demandez à vos clients. Ils seront d’accord.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La folie coûteuse d’un arriéré de produit surdimensionné

Le par mopertodans agile, best practicesLaisser un commentaire

Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .

The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers

https://age-of-product.com/oversized-product-backlog/

Les coûts d’un arriéré de produit surdimensionné

Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.

Les effets secondaires coûteux d’un arriéré de produit surdimensionné

Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.

Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.

#1 – Encourage le gaspillage

Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.

#2 – Augmente les risques du piège des coûts irrécupérables

Les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse ou décide maintenant. Relisez ce billet.

Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.

#3 – Conduit à la paralysie d’analyse

Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.

#4 – Nuit à l’engagement des parties prenantes

Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.

#5 – Produit un effet d’éviction

Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.

#6 – Inhibe l’innovation

Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.

#7 – Donne un faux sentiment de sécurité

Guide téléchargeable gratuitement

Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.

#8 – Encourage l’optimisation précoce

Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comment contrer au mieux les effets d’un Product Backlog surdimensionné

Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :

#1 – Adoptez la simplicité

Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.

#2 – Limitez les travaux en cours (Work in Progress : WiP)

Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.

#3 – Affinez régulièrement le Product Backlog

Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.

#4 – Affinez juste-à-temps

Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.

#5 – Hiérarchisez et dépriorisez

Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.

#6 – Responsabilisez les équipes

Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !

#7 – Faites la promotion un dialogue ouvert

Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.

#8 – Favorisez l’apprentissage continu et l’adaptation

Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.

Pour terminer

Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.

Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.

Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?

Comment présenter les user stories à votre équipe ?

Le par mopertodans agile, best practicesLaisser un commentaire

Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »

Astuce #1: Commencez par quelques définitions.

Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »

Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.

Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.

Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.

Astuce #2: Ajoutez le bon niveau de détails au bon moment.

Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.

Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.

Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.

Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.

Astuce #3: Apprenez la méthode SPIDR pour découper les histoires

SPIDR : Spike, Path, Interfaces, Data, and Rules. (Spike*, chemin, interfaces, données et règles). Vous pouvez lire sur chaque technique et obtenir une affiche SPIDR gratuite ici.

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.

J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,

P.S. Il ne vous reste que deux chances d’assister à un cours Better User Stories en direct avec Mike avant la fin de l’année. https://www.mountaingoatsoftware.com/training/courses/better-user-stories

* Spike : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Les parties prenantes insistent sur le fait qu’elles ont besoin d’une fonctionnalité ou histoire utilisateur MAINTENANT !

Le par mopertodans agileLaisser un commentaire

Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.

Publié par Mike Cohn dans la lettre hebdomadaire de Mountain Goat Software

J’ai remarqué quelque chose à ce sujet, cependant.

La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.

Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.

Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.

J’ai eu beaucoup de succès en répondant quelque chose comme ceci

Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?

Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.

Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.

PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Pour une priorisation Agile optimale, concentrez-vous sur les bénéfices !

Le par mopertodans agileLaisser un commentaire

Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?

Prioritisation in Agile: Focus on the Benefits par Quay Consulting

https://www.quayconsulting.com.au/news/prioritisation-in-agile-focus-on-the-benefits/

L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.

Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.

Relisez ce billet

Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.

Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.

Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?

Contraintes de priorisation

Le time-boxing est une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.

Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.

Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.

Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?

Facteurs de priorisation

Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.

Par exemple :

  • Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
  • Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
  • Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
  • Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
  • Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
  • Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?

Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.

Le processus de priorisation et le contexte

Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles.  Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.

Il y a un peu plus…

Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables.  La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.

Considérons ce que chaque composant représente :

  • Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
  • Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
  • Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
  • Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.

Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.

Maintenir un focus laser sur les bénéfices et le retour sur investissement

Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.

La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.

Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.

Comment découpez-vous votre travail ?

Le par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

Il existe une variété infinie de projets, cependant seulement 3 approches sont utilisées par la plupart des équipes qui développent des WBS.

 

How do you breakdown your work? par Kiron Bondale

https://kbondale.wordpress.com/2022/05/15/how-do-you-breakdown-your-work/

Le PMBOK V7 sur Amazon

La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».

Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.

Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.

  1. Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
  2. Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
  3. Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.

Une approche axée sur les livrables

Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.

Une approche axée sur les phases

Livre sur Amazon

Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.

Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.

Une approche axée sur la responsabilité

Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.

Sondage auprès des professionnelles et professionnels du management de projet

J’ai mené un sondage dans le groupe PMI’s LinkedIn Project, Program and Portfolio discussion group ainsi que dans  la communauté ProjectManagement.com pour évaluer la répartition dans l’utilisation de ces 3 approches.

Sur les 141 réponses combinées :

  • 57 % utilisaient une ventilation axée sur les livrables
  • 28 % une approche axée sur les phases
  • 9 % une approche axée sur la responsabilité
  • Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.

Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.

Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.

Quelles sont les caractéristiques clés des Product Owners qui sont des CRACKs ?

Le par mopertodans agile, pmo et portofolioLaisser un commentaire

En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !

  • Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
  • Livre référence sur Amazon

    Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?

  • Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
  • Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
  • Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?

Merci à Kiron Bondale pour le pointeur sur « Balancing Agility and Discipline: a guide for the perplexed », publié par Addison-Wesley en 2004

Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !

Visitez le site de notre partenaire Virage Group

La controverse sur les Story Points : Quelle est leur réelle valeur ?

Le par mopertodans agileLaisser un commentaire

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

The Story Point Controversy par Natalie Barnes

https://resources.scrumalliance.org/Article/story-point-controversy

L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.

Qu’est-ce qu’un Story Point ?

Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.

Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.

Relisez ce billet sur « pourquoi Fibonacci ? »

Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.

Comment les story points sont-ils utilisés dans les sprints ?

Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.

L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).

Pourquoi les story points peuvent-ils être sujets à controverse ?

Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.

Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.

La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.

Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.

Trouvez un équilibre

Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.

Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.

Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comportements de leadership pour une culture de changement agile

Le par mopertodans agile, leadership, pmo et portofolio, pointeurs utilesLaisser un commentaire

L’agilité est un comportement et des attitudes, pas une méthodologie ni un ensemble de processus ou de techniques

Leadership behaviours for an Agile Change culture

https://agilechangemanagement.co.uk/leadership-behaviours-for-an-agile-change-culture deMelanie Franklin

Téléchargez le livre blanc en anglais

Nous savons que l’agilité n’est pas une méthodologie ni un ensemble de processus ou de techniques. L’agilité est le comportement et les attitudes qui permettent aux individus et aux organisations de se déplacer rapidement et facilement.

Au niveau individuel, cette capacité conduit à l’innovation, à la créativité, à l’adoption rapide de nouvelles méthodes de travail.

Au niveau organisationnel, ce comportement est démontré par des améliorations continues, la recherche de nouveaux apprentissages, la volonté d’adopter de nouvelles approches et, en fin de compte, une mise sur le marché de nouveaux produits et services aux clients plus rapide et plus créative.

Les comportements agiles sont soutenus par de nouvelles façons de planifier et de hiérarchiser le travail, mais ils ont besoin d’un environnement qui encourage et récompense leur utilisation.

Les leaders sont les principaux acteurs dans la création de cet environnement.

Les leaders ne sont pas limités à ceux qui ont un pouvoir hiérarchique au sein de leurs organisations.

Un leader est quelqu’un que les autres suivent volontiers.

Je travaille avec de nombreuses organisations à différentes étapes dans l’agilité, et j’ai observé un groupe central de comportements travaillant ensemble, qui permettent aux processus et techniques agiles de s’épanouir :

  1. Imaginez l’état futur
  2. Faites évoluer votre vision
  3. Identifiez les petites étapes
  4. Vivez dans l’incertitude
  5.  Prenez des décisions
  6. Sollicitez l’avis des autres
  7. Abandonnez le contrôle

Si vous occupez un poste de leadership, j’ai écrit un document qui vous donnera l’occasion de comparer votre propre comportement à l’excellence agile et d’identifier les domaines à améliorer.

Si vous êtes manager de projet/programme, PMO ou Product Owner, cela vous donnera beaucoup d’idées sur ce dont il faut discuter avec votre sponsor.

https://agilechangemanagement.co.uk/wp-content/uploads/2022/04/Leadership-behaviours-for-an-Agile-Change-culture.pdf

Téléchargez ce guide sur le site de notre partenaire Virage Group

Avec Scrum, quand un sprint est-il terminé ?

Le par mopertodans agileLaisser un commentaire

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé.

In Scrum, when is a sprint over?

https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/ par Leon Tranter

Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’est-ce qu’un sprint ?

Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.

Il n’y a pas d’activité en dehors du sprint.

Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.

Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.

Pourquoi est-il timeboxé ?

La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.

Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !

Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !

La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).

Quand un sprint est-il terminé ?

La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).

Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).

Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).

Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.

L’important est que la timebox régulière soit respectée.

De quelles autres façons un sprint peut-il se terminer ?

Il n’y a que deux autres façons dont un sprint peut se terminer.

La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.

Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.

L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.

Choses à faire avant la réunion de planification du sprint

Le par mopertodans agile, experience sharingLaisser un commentaire

Découvrez ce que vous devriez faire avant même le début de votre réunion de planification de sprint afin de faire du prochain sprint un succès.

https://blog.gurock.com/sprint-planning/ par Nishi Grover Garg

Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?

Priorisez le Product Backlog, l’arriéré de produit

La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.

Détaillez les fonctionnalités

Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.

Décidez d’une définition de done

Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.

Soignez les user stories

Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.

Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.

Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.

Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.

Commencez par le design

De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.

De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.

Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.

Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi  Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.

Consultez  son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.

CertYou est partenaire de DantotsuPM

Priorisation des tâches : Maintenant, Ensuite, Plus tard, Jamais (améliorons le MoSCoW)

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.

Now, Next, Later, Never (improving MoSCoW)

https://watirmelon.blog/2019/10/14/now-next-later-never-improving-moscow/ par Alister Scott

Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.

Nous avons à l’origine commencé par utiliser la méthode de MoSCoW  pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.

Méthode MoSCoW sur Wikipedia

Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.

En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.

Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.

J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.

Comment abordez-vous l’établissement de la priorité de vos exigences ?

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

Biais Cognitif – Le biais de projection

Le par mopertodans experience sharing1 commentaire

La tendance à supposer avec confiance que les autres partagent notre mode de pensée, nos attitudes et nos croyances est connue sous le nom de biais de projection.

Un effet connexe que nous avons déjà abordé sur ce blog est le biais de faux consensus qui pousse cette tendance un peu plus loin en nous faisant croire que les autres « sont également d’accord » avec nos points de vue.

Ce biais nous laisse de plus penser que nos habitudes et préférences resteront les mêmes au fil du temps. Nous projetons nos préférences actuelles dans l’avenir comme si nos goûts futurs correspondraient à nos goûts actuels.

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

Il y a des moments dans nos projets où il devient important de décider pour l’avenir. Et nous ne prenons pas toujours la meilleure décision. Le biais de projection devient un problème lorsque nous laissons les décisions prises en fonction de nos ressentis et préférences actuels affecter nos objectifs à long terme.

Lorsque vos commanditaires définissent leurs exigences impératives au début du projet, ils doivent anticiper à quel point celles-ci auront probablement évolué d’ici la fin du projet dans 3, 6 ou 18 mois par exemple. Se sont-ils projetés dans le futur ? En sont-ils capables ?

Le biais de projection peut aussi amener ces personnes à demander plus de fonctionnalités et de changements qu’elles ne peuvent en absorber sur la période. Cela revient à commander leurs desserts (des fonctionnalités non impératives) en début de repas alors qu’elles n’auront plus faim bien avant la fin du plat de résistance (les fonctionnalités critiques).

Comment éviter le plus possible ce travers ?

La priorisation des besoins et exigences est critique, que ce soit en approche prédictive comme en approche Agile. Il s’agit de ne pas prévoir plus de travail que réellement nécessaire, de prioriser le livrable qui va vraiment apporter des bénéfices concrets rapidement sur d’autres plus annexes. Il reste vrai qu’avoir la vue à long terme des changements que va apporter le projet est absolument critique et va guider le séquencement des travaux et l’échelonnement des livrables.

Ce biais peut-il nous être utile ?

Votre expérience de manager de projet peut vous aider grandement à utiliser les faiblesses de ce biais pour faire réfléchir vos clients et futurs utilisateurs de vos livrables ou votre product owner. De simples questions de votre part peuvent les amener à reconsidérer leur priorisation et à réfléchir à leur future situation.

Par exemple :

  • J’entends bien que cette fonctionnalité dans le portail client est aujourd’hui impérative car c’est notre principal parcours pour les utilisateurs Business to Business (B2B). Mais ne pensez-vous pas que l’arrivée des Application Programmable Interfaces (APIs) et des interfaces vocales pourraient changer la donne d’ici 12 mois ? Quels en seraient les impacts sur le parcours du client B2B ?
  • Nos processus de vente sont aujourd’hui très centrés sur des rencontres en face à face entre nos prospects et clients et nos vendeurs. La priorisation du déploiement de couteuses tablettes à notre force de vente est donc aujourd’hui particulièrement attractive pour accroitre leur productivité. Si la pandémie devait durer plusieurs semestres ou années et que les rencontres en face à face soient de moins en moins fréquentes, investiriez-vous toujours autant sur ces technologies ?
FDF est partenaire de DantotsuPM

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

Le par mopertodans pointeurs utilesLaisser un commentaire

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