Comment nous avons accidentellement inventé les histoires de travail, les Job Stories

La chose la plus formidable que vous puissiez comprendre en construisant un produit est quelles sont les motivations derrière les actions des gens.

How we accidentally invented Job Stories

https://www.intercom.com/blog/accidentally-invented-job-stories/ par Paul Adams

Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.

nous écoutons les clients

Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.

Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.

Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.

Les Personas pour l’empathie, pas pour la pensée nouvelle

Livre sur Amazon

Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.

Popularisé par Alan Cooper dans The Inmates are Running the Asylum, ils sont depuis devenus l’un des outils le plus largement utilisés dans le panel de recherche et conception de l’équipe.

 

Livre sur Amazon

Cooper a aussi écrit un livre fantastique appelé About Face que je recommande à tous les designers qui rejoignent mon équipe, mais je leur dis de sauter les chapitres sur des personas.

Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.

Nous n’avons jamais utilisé de personas chez Intercom.

Les motivations des personnes peuvent être très similaires quelques soient les démographies

La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.

Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.

Ici les clients sont importants

Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.

Passer de ce que veulent les gens à pourquoi ils le veulent

les 5 pourquoi, les 5 whys
Utilisez la technique des 5 pourquoi (relisez ce billet)

Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.

Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :

  1. Les gens sont des experts dans leur problème pas la solution, mais il est plus naturel de suggérer une solution en forme d’une demande de fonctionnalité. La description d’une suggestion de solution est plus facile que la description d’un problème, mais vous devez retourner vers ces personnes avec des questions pour vraiment comprendre leur problème.
  2. Quand ils répondent, leur réponse initiale vous dira ce qu’ils veulent, sous forme d’attributs, mais pas pourquoi cela importe. Donc vous devez continuer à fouiller dans leurs motivations.

Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.

Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?

Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.

Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.

En dehors des Personas, un autre outil très populaire est les User Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.

Histoires de travail : Capturer des situations, motivations et résultats

Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.

CertYou est partenaire de DantotsuPM

Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :

 [ Quand _____]  [je veux faire _____]  [pour pouvoir _____]

‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.

Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.

Nous sommes impatients de vous revoir !

Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.

Téléchargez le modèle au format  Word ou PDF

Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.

Mais les personas sont :
  • Laborieux à bien créer
  • Trop concentrés sur les différences entre les personnes
  • Et difficiles à se rappeler et à référencer.
En fait :
  • Beaucoup de personnes avec des attributs divers ont des motivations très similaires
  • Ces motivations sont faciles à rechercher
  • Et le focus sur ce que vous construisez peut être capturé en une série de phrases courtes et mémorisables.
Si cela ne vous convainc pas, souvenez-vous que les personas contraignent artificiellement le l’ensemble du marché pour votre produit. Nous misons tout sur les Histoires de Travail.

Soyez réaliste dans votre choix d’utiliser une approche Agile (ou pas) !

Soyez réaliste dans votre choix d’utiliser une approche Agile (ou pas) !

Pour réussir avec Agile, assurez-vous d’utiliser des critères bien réfléchis pour qualifier vos projets comme de bons candidats pour une approche Agile.

Realistic Agile selection

 http://www.bonniebiafore.com/realistic-agile-selection/ par Bonnie Biafore

Voici des choses à considérer en établissant vos critères de qualification Agile

La priorité du projet pour obtenir les bonnes personnes

Avoir les bons membres techniques et business dédiés au projet est crucial. Agile produit rapidement des résultats avec une grande intensité pour ses participants. Agile exige les personnes business et techniques les plus critiques, celles qui sont essentielles à opérer votre business. Donc il est important de donner la priorité au temps qu’ils peuvent contribuer au projet. Accepter des compromis difficiles entre le travail de projet et les considérations opérationnelles est la clé.

Le bon niveau de connaissances

La connaissance en profondeur des secteurs business et techniques impactés par le projet est cruciale. Les experts métier travaillant étroitement avec les experts techniques de l’équipe sont au cœur de l’approche agile. La caractéristique première qui rend les méthodologies Agile agiles est la responsivité de la méthode à des besoins qui évoluent. Des personnes techniques et business bien informés doivent constamment réévaluer les livrables du projet et  les besoins du business à un niveau macro et micro et prioriser les fonctionnalités nécessaires au client final. Sans connaissance et disponibilité pour réaliser ces évaluations, la base même des méthodes agiles s’effrite.

Un sponsor avec une mentalité agile

Le sponsor doit désirer participer aux fréquentes revues du produit en développement, qui sont fondamentales dans l’approche agile.  D’autre part, un sponsor qui veut un ensemble linéaire, méthodique, planifiés d’objectifs livrés sur un échéancier préétabli aura du mal avec les livrables Agile. La bonne capacité de réaction de l’approche Agile aux changements de conditions du business et environnement d’apprentissage diffèrent beaucoup des méthodes traditionnelles de management de projet. Les sponsors qui résistent à la nature évolutionnaire de l’agilité créent des difficultés qui peuvent faire couler le projet.

La capacité de co-localiser ou simuler la co-localisation

Agile implique un dialogue profond, interactif et parfois difficile, qui produit de meilleurs résultats. Accroitre ce dialogue exige l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de l’équipe projet si possible. Si vous ne le pouvez pas, simulez cette co-localisation avec les meilleurs outils vidéo et audio que vous pouvez trouver. Essayer de faciliter un dialogue agile avec des outils de communication sous performants ressemble à essayer de remorquer une grosse caravane avec une tondeuse à moteur. Cela n’a tout simplement aucun sens.

Synergie entre les membres business et techniques de l’équipe

Les méthodologies agiles exigent de dédier des experts métiers et techniques ouverts à essayer de nouvelles idées et à se supporter les uns les autres. Vous avez besoin d’un coach agile qui comprenne et puisse gérer la dynamique humaine et favoriser un environnement où les membres d’équipe partagent aisément leurs idées et soucis. Une équipe agile doit s’entendre bien pour réussir.

Un produit qui peut être construit itérativement

Les meilleures qualités d’Agile viennent de livrer des solutions par petits livrables en apprenant de chaque itération. En plus des produits logiciels, d’autres produits peuvent être construits de cette façon. Avec un peu de créativité, déménagements, mises en œuvre de nouveaux processus et même certains projets de construction peuvent utiliser des méthodes agiles. Si vous pensez à une façon dont votre produit final peut être construit en étapes itératives, le projet peut être un bon candidat pour une approche Agile.

CertYou est partenaire de DantotsuPM

Que diriez-vous d’un jeu de cartes gratuit de 50 idées pour améliorer rapidement vos User Stories (Histoires d’Utilisateur / Exigences en mode Agile) ?

Si vous avez aimé le livre 50 Quick Ideas to Improve User Stories mais avez des difficultés à jongler avec les 50 idées dans votre tête, les avoir en un jeu de cartes de référence est très pratique.

Livre sur Amazon

Il est maintenant disponible sous license Creative Commons Attribution-ShareAlike 4.0 International License. Vous pouvez imprimer les cartes vous-même, les adapter et les utiliser dans tout travail.

Free card deck for 50 Quick Ideas to Improve User Stories

https://gojko.net/2019/10/15/50-qi-cards.html par Gojko Adzic

Nous mettons notre notre célèbre jeu de carte en libre impression, sous « creative commons ». Un excellent rappel de toutes les astuces du livre Fifty Quick Ideas To Improve Your User Stories

Téléchargez le PDF imprimable

Et pour un peu de fun en ces temps si compliqués, je vous conseille cette petite chanson sur Scrum qui vous rappellera peut-être des souvenirs…

Hey, Scrum Master (parody of Hey, Soul Sister by Train)

Le refrain en français donne à peu près ceci:

Hé, Scrum Master, je sais que nous sommes un désastre
Chaque sprint que nous sprintons et incréments que nous créons ne sont pas transparents
Hé, Scrum Master, je ne veux pas manquer une seule cérémonie Scrum de ce Sprint
Inspecter, inspecter et adapter, inspecter et adapter
Inspecter, inspecter et adapter, inspecter et adapter

CertYou est partenaire de DantotsuPM

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

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

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

Tous vos clients ou prospects sont-ils identiques ?

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

Comment éviter le plus possible ce travers ?

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

Ce biais peut-il nous être utile ?

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

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

CertYou est partenaire de DantotsuPM

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

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

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

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

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

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

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

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

Pour rappel

CertYou est partenaire de DantotsuPM

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

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

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

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

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

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

Le guide Scrum 2020 est paru le 18 Novembre

  1. Guide téléchargeable gratuitement

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

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

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

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

CSP est partenaire de DantotsuPM

 

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

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

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

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

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

FDF est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

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

CertYou est partenaire de DantotsuPM

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

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

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

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

Hexagon est partenaire de DantotsuPM

 

Techniques Agiles : Les objectifs dans Scrum (Scrum Goals)

Agile Techniques: Scrum Goals

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

Guide téléchargeable gratuitement

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

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

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

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

CertYou est partenaire de DantotsuPM

Des Objectifs de Sprint Efficaces

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

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

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

Planisware est partenaire DantotsuPM

Le guide Scrum 2020 est paru le 18 Novembre

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

Plusieurs notables évolutions

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

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

Des pointeurs supplémentaires:

CertYou est partenaire de DantotsuPM

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

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

Que Scrum signifie-t-il pour vous ?

CertYou est partenaire de DantotsuPM

Quelques pistes pour partager votre expérience :

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

Michel.


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

Inscrivez-vous rapidement

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

Inscriptions