Qu'est-ce que l'Agilité ?

Une philosophie centrée sur l’humain et l’adaptabilité

Une approche itérative et incrémentale

Un cadre d’équipe collaboratif et responsabilisant

L'Agilité c'est une philosophie, pas un Framework ou une méthodologie !

Une philosophie centrée sur l’humain et l’adaptabilité

L’Agilité repose avant tout sur des valeurs et des principes issus du Manifeste Agile (2001). Elle privilégie :

• les interactions humaines plutôt que les processus rigides,

• la collaboration avec le client plutôt que la négociation contractuelle,

• la réactivité au changement plutôt que la planification exhaustive.

En résumé : on s’adapte en permanence pour créer de la valeur, plutôt que de suivre aveuglément un plan figé.

Une approche itérative et incrémentale

Les projets agiles avancent par petites étapes régulières (itérations ou sprints), à la fin desquelles un résultat concret et testable est livré :

• Cela permet un retour rapide des utilisateurs,

• On ajuste au fur et à mesure selon les besoins réels,

• On réduit le risque d’échec à grande échelle.

En résumé : on apprend en faisant, en livrant souvent, et en s’améliorant à chaque boucle.

Un cadre d’équipe collaboratif et responsabilisant

L’Agilité mise sur :

• des équipes autonomes et auto-organisées,

• une communication constante (daily meetings, revues, rétrospectives),

• une amélioration continue (feedback régulier, rétrospectives, ajustements).

En résumé : l’équipe est au cœur du dispositif et co-construit la solution avec les parties prenantes.

Pourquoi utiliser l'Agilité ?

Mieux répondre aux besoins réels du client

Réduire les risques et gagner en flexibilité

Valoriser les équipes et améliorer la collaboration

C’est une réponse concrète aux limites des méthodes traditionnelles dans un monde complexe et changeant.

Mieux répondre aux besoins réels du client

L’agilité permet une livraison fréquente et rapide de fonctionnalités utilisables. Cela favorise :

• des retours clients réguliers,

• des ajustements en continu,

• et donc une meilleure adéquation avec les attentes.

Résultat : le produit final correspond mieux à ce que le client veut vraiment, même si ses besoins évoluent en cours de route.

Réduire les risques et gagner en flexibilité

Grâce à son approche itérative et incrémentale, l’agilité :

• limite les gros échecs en fin de projet,

• détecte les problèmes tôt,

• et permet de s’adapter rapidement à de nouveaux contextes (marché, technologie, changement interne...).

Résultat : on minimise les pertes et on maximise la capacité à s’adapter.

Valoriser les équipes et améliorer la collaboration

L’agilité repose sur des équipes responsabilisées, auto-organisées, avec des rituels réguliers (daily, rétrospective, sprint review...). Cela :

• renforce la motivation et l’implication,

• améliore la communication interne et avec les parties prenantes,

• et encourage une amélioration continue.

Résultat : une meilleure cohésion d’équipe et une dynamique positive de travail.

Les méthodologies Agile

Scrum

Axée itérative centrée sur des sprints pour livrer un produit fonctionnel.

Kanban

Axée visuelle de gestion de flux, basée sur un tableau de tâches

Extreme Programming

Axée sur la qualité du code et la collaboration développeurs-client.

Qu'est-ce que SCRUM ?

Une organisation par itérations courtes : les Sprints

Des rôles bien définis pour une équipe autonome

Des rituels pour structurer et améliorer le travail

Pourquoi utiliser SCRUM ?

Pour livrer rapidement de la valeur

Pour s’adapter en continu au changement

Pour renforcer la collaboration et l’autonomie des équipes

Pour livrer rapidement de la valeur

Scrum fonctionne en sprints courts, ce qui permet de produire et livrer des fonctionnalités utilisables très rapidement.
Chaque incrément est testable et améliorable.

Bénéfice : on répond plus tôt aux besoins des utilisateurs et on peut ajuster rapidement.

Pour s’adapter en continu au changement

Grâce à ses rituels fréquents (revue, rétrospective, daily), Scrum permet d’ajuster le cap à tout moment.
Le backlog est priorisé en permanence selon la valeur métier et le retour des parties prenantes.

Bénéfice : on évite les effets tunnel et on limite les erreurs coûteuses.

Pour renforcer la collaboration et l’autonomie des équipes

Scrum repose sur une équipe auto-organisée, des rôles bien définis et une communication constante.
Cela stimule :

• l’implication individuelle,

• l’intelligence collective,

• l’amélioration continue.

Bénéfice : une meilleure qualité de travail, plus de motivation et un climat de confiance.

Le guide SCRUM

Je vous invite à lire le document officiel :

Lien vers le guide officielle SCRUM en français

Synthèse du guide

Nous allons réaliser une rapide synthèse du guide pour revoir ensemble les points clés.

Le guide ne doit pas être une série de règles à suivre scrupuleusement, son but est de guider votre équipe et vous pouvez ajouter, retirer, modifier tout élément pour améliorer votre organisation.

Bien sûr, les modifications doivent suivre la philosophie Agile pour ne pas tomber dans de mauvaises dérives.

Théorie de Scrum

Scrum repose sur la théorie empirique de la gestion de projet, appelée empirisme. L’empirisme signifie que la connaissance vient de l’expérience et des décisions basées sur l’observation.

Trois pilliers :

1. Transparence - Tout le monde partage une compréhension claire et commune de ce qui est fait et comment.

2. Inspection - L’équipe observe fréquemment son travail et son avancement.

3. Adaptation - Si un écart est détecté, l’équipe s’adapte rapidement pour corriger la trajectoire.

Les 5 valeurs de Scrum

Les membres de l’équipe respectent ces valeurs au quotidien :

1. Engagement - Chacun s’engage à atteindre les objectifs de l’équipe.

2. Courage - L’équipe a le courage de faire ce qui est juste, de dire la vérité, de soulever les obstacles.

3. Focus (Concentration) - L’équipe se concentre sur le travail du Sprint et les priorités définies.

4. Openness (Ouverture) - Les membres sont ouverts aux idées, aux retours et aux changements.

5. Respect - Chacun respecte les compétences, opinions et rôles des autres.

Les 3 rôles de Scrum : Le Scrum Team

Dans Scrum, il n’y a qu’une seule équipe appelée Scrum Team, composée de 3 rôles complémentaires :

Product Owner (PO)

Scrum Master (SM)

Développeurs

Product Owner

Responsable de maximiser la valeur du produit.

Il gère le Product Backlog, c’est-à-dire :

• Il définit et priorise les besoins (les User Stories),

• Il est l’interface avec les parties prenantes (clients, métier...),

• Il valide que ce qui est produit apporte de la valeur.

Il "décide" quoi faire, pas comment le faire.

Scrum Master

Facilitateur du cadre Scrum, garant du bon fonctionnement de l’équipe dans l’esprit agile.
Son rôle :

• Aider l’équipe à comprendre et appliquer Scrum correctement,

• Éliminer les obstacles à l’avancement,

• Favoriser l’amélioration continue (notamment via les rétrospectives),

• Coacher l’équipe et l’organisation sur l’agilité.

Il n’a aucun pouvoir hiérarchique, mais un rôle de support.

Développeurs

Ce sont les membres de l’équipe qui construisent l’incrément à chaque sprint.
Ils :

• Planifient le travail du Sprint avec le PO,

• S’auto-organisent pour atteindre l’objectif,

• Garantissent la qualité de l’incrément livré.

Ce sont des experts techniques ou fonctionnels, responsables collectivement du résultat.

Attention, c'est un sens large, dès que quelqu'un contribue au développement du produit !

Les rituels (évènements)

Scrum possède plusieurs rituels (évènements à faire à chaque itération) :

Les rituels

Les rituels clés :

• Sprint - Cadre de travail

• Sprint Planning - Démarrage

• Daily Scrum - Suivi quotidien

• Sprint Review - Bilan produit

• Sprint Retrospective - Bilan d’équipe

Les rituels annexes :

• Backlog Refinement - Trier et prioriser
• Example Mapping - Définir les US
• Priority Meetings - Définir les priorités

Le Sprint

Le Sprint est l’unité de base du temps dans Scrum.
C’est une itération fixe, durant laquelle l’équipe produit un incrément utilisable et potentiellement livrable.

De 1 à 4 semaines, toujours de durée constante pour assurer un rythme stable.

Objectifs du Sprint :

1. Atteindre un Sprint Goal (objectif clair)

2. Livrer un incrément de qualité

3. Favoriser l’adaptation rapide

Le Sprint - Contenu et Règles

Le Sprint contient tous les événements Scrum :

• Sprint Planning - planifier le travail,

• Daily Scrum - suivre et ajuster chaque jour,

• Sprint Review - présenter ce qui a été fait,

• Sprint Retrospective - s’améliorer en équipe.

Règles clés

• Aucun changement majeur n’interrompt un Sprint en cours.

• L’objectif du Sprint (Sprint Goal) ne change pas.

• Le scope (contenu) peut être ajusté si nécessaire par les développeurs avec le Product Owner.

Le Sprint Planning

Le Sprint Planning ouvre chaque Sprint. Il permet à toute l'équipe de décider quoi faire et comment le faire pendant l’itération.

1. Pourquoi ce Sprint est-il important ?
   On définit le Sprint Goal, une vision commune et motivante.

2. Que pouvons-nous livrer pendant ce Sprint ?
   L’équipe sélectionne les items prioritaires du Product Backlog à développer. Ces éléments doivent être clairs, priorisés et estimés.

3. Comment allons-nous faire le travail ?
   Les développeurs découpent les items sélectionnés en tâches techniques dans un Sprint Backlog. Ils s’auto-organisent pour planifier leur travail.

Le Sprint Planning - Participants et Durée

• Product Owner : apporte la vision, clarifie les besoins.

• Développeurs : estiment, s’engagent sur ce qu’ils peuvent livrer.

• Scrum Master : facilite la réunion, s’assure que Scrum est bien appliqué.

Durée

• Maximum 8 heures pour un Sprint de 1 mois.

• Proportionnellement moins pour un Sprint plus court (ex. 4h pour 2 semaines).

Daily Scrum

Le Daily Scrum est une réunion courte (15 minutes maximum) tenue chaque jour du Sprint par les développeurs pour synchroniser l’équipe pour atteindre l’objectif du Sprint.

Le Daily Scrum reste centré sur :

• Ce qui a été fait depuis le dernier Daily,

• Ce qui sera fait d’ici le prochain,

• Les obstacles rencontrés,

• Les ajustements nécessaires pour tenir le Sprint Goal.

Le format est libre, tant qu’il aide l’équipe à inspecter et adapter son plan quotidiennement.

Daily Scrum - Participants et limites

• Les développeurs uniquement : ce sont eux qui parlent et s’auto-organisent.

• Le Scrum Master et le Product Owner peuvent y assister, mais ne dirigent pas la réunion.

Ce que le Daily n’est pas :

• Ce n’est pas un reporting au Scrum Master ou au PO.

• Ce n’est pas un long débat technique ou une réunion de résolution de problèmes.

Sprint Review

Le Sprint Review (ou revue de Sprint) est une réunion qui a lieu à la fin du Sprint. Elle permet de présenter l’incrément livré et de recueillir des retours concrets des parties prenantes :

• Présentation de l’incrément terminé (fonctionnalités développées),

• Échange avec les parties prenantes (clients, utilisateurs, métiers),

• Ce qui a été fait pendant le Sprint, ce qui a changé dans l’environnement ou les besoins, les prochaines priorités.

Résultat : une vision partagée de l’état du produit, et un Product Backlog mis à jour en fonction des retours.

Sprint Review - Participants et durée

• Toute la Scrum Team (PO, SM, Développeurs),

• Parties prenantes invitées par le PO (clients, utilisateurs, responsables métiers, etc.).

Durée

• Maximum 4 heures pour un Sprint d’un mois (à ajuster selon la durée du Sprint, 2 heures pour 2 semaines).

Sprint Retrospective

La Sprint Rétrospective est la dernière réunion du Sprint.
Elle permet à la Scrum Team de réfléchir sur son fonctionnement et de s’améliorer en continu :

• Revue de l’ambiance d’équipe, des processus, des outils, de la collaboration,

• Identification des points positifs et des points à améliorer,

• Choix d’actions simples et réalistes à tester dès le Sprint suivant.

Ce que ce n’est pas :

• Ce n’est pas une réunion de blâme.

• Ce n’est pas une réunion technique.

Sprint Retrospective - Participants et durée

• Toute la Scrum Team (Product Owner, Scrum Master, Développeurs),

• Pas de parties prenantes externes : c’est un moment interne de transparence et de confiance.

Durée

• Maximum 3 heures pour un Sprint d’un mois (moins pour les Sprints plus courts, 1 heure pour 2 semaines).

Backlog Refinement

Le Backlog Refinement (ou "affinage du Product Backlog") est une activité continue, au cours de laquelle la Scrum Team prépare les éléments à venir pour les rendre clairs, compréhensibles et réalisables : 

• Découper des gros items (epics) en éléments plus petits,

• Ajouter des détails ou critères d’acceptation,

• Estimer (souvent avec des story points),

• Clarifier les besoins métier avec le Product Owner,

• Réévaluer la priorité des éléments si besoin.

Backlog Refinement - Participants et durée

• Product Owner : responsable du Product Backlog, apporte les besoins.

• Développeurs : apportent leur expertise technique, posent des questions, estiment.

• Scrum Master : facilite si nécessaire, surtout si l’équipe débute.

Durée

• Ce n’est pas un événement officiel Scrum, donc pas de durée fixe. Recommandé : 5 à 10 % du temps du Sprint (ex. : 1 à 2 heures pour un Sprint de 2 semaines).

Example Mapping

L’Example Mapping est une technique de discussion structurée pour explorer et affiner une User Story, en équipe.
Elle permet de partager une compréhension commune entre Product Owner, développeurs et testeurs, en se basant sur des exemples réels.

Participants :

• Product Owner (avec Scrum Master en support)

• Développeurs

• Testeurs / UX / Métier

​Durée : Rapide : 15 à 30 minutes par User Story, idéal pour un atelier de refinement.

Example Mapping - Schema

Comment bien rédiger les exemples ?

Pour standardiser et éviter d'avoir des exemples différents pour chacun, on utilise alors le Gherkin. Cela permet de se rapprocher d'une syntaxe plus algorithmique et permet à toute l'équipe de participer à la réflexion de la logique de l'US.

Voyons ensemble sa syntaxe et son fonctionnement :

 https://cucumber.io/docs/gherkin/reference/

Les artéfacts

Les artéfacts Scrum servent à rendre le travail visible, à focaliser l’équipe sur la livraison de valeur, et à favoriser l’inspection et l’adaptation :

• Product Backlog - Liste évolutive, priorisée et visible de tout ce qu’il y a à faire sur le produit.
• Sprint Backlog -  Sélection d’items du Product Backlog engagés par les développeurs pour le Sprint, + le plan de réalisation + le Sprint Goal.
• Increment - Livrable fonctionnel à la fin de chaque Sprint.
• Definition of Done - Ensemble de critères de qualité partagés que chaque incrément doit respecter pour être considéré comme terminé.

Le Product Backlog

C’est une liste évolutive, ordonnée et transparente de tout ce qui doit être fait pour améliorer le produit.

Son objectif est de maximiser la valeur du produit en définissant, priorisant et rendant visibles les besoins à venir.

Seul le Product Owner est responsable de cet artefact.

Chaque élément est un Product Backlog Item (PBI), par exemple : User Stories, Bugs à corriger, Tâches techniques, Explorations ou prototypes.

Chaque PBI peut contenir une description claire, une valeur métier, des critères d’acceptation, une estimation.

Le Product Backlog - Points clés

• Évolutif : le Backlog change et s’enrichit constamment,

• Priorisé : les éléments les plus importants sont en haut,

• Clair et compréhensible : pour que l’équipe puisse s’y préparer,

• Affiné régulièrement lors des sessions de Backlog Refinement.

Le Sprint Backlog

Il représente l’engagement des développeurs pour le Sprint en cours. Son objectif est de donner une vision claire et partagée de ce que l’équipe va faire pendant le Sprint, et comment elle va s’y prendre.

Son contenu :

1. Les PBIs sélectionnés pour ce Sprint (objectifs de livraison).

2. Le Sprint Goal (objectif unique, motivant et clair).

3. Un plan d’action pour livrer ces items (souvent sous forme de tâches techniques).

Le Sprint Backlog - Responsabilités et limites

Le Sprint Backlog est créé par les développeurs lors du Sprint Planning. Il est mis à jour librement par les développeurs tout au long du Sprint. Le Product Owner n’intervient pas dans sa gestion, mais il peut clarifier les besoins si nécessaire.

Évolutif mais stable

• Le Sprint Backlog évolue quotidiennement : les tâches peuvent être affinées ou ajustées.

• Mais l’objectif du Sprint (Sprint Goal) reste fixe pendant toute la durée du Sprint.

L'Incrément

C’est le livrable produit à la fin du Sprint, qui doit être terminé, testable et potentiellement livrable.

Son objectif est de fournir un pas de plus vers l’objectif produit en livrant une fonctionnalité concrète, utilisable ou testable par les parties prenantes : 

• Il intègre le travail terminé pendant le Sprint,

• Il respecte la Definition of Done (DoD),

• Il est potentiellement livrable, même s’il n’est pas encore mis en production,

• Plusieurs incréments peuvent être créés dans un même Sprint.

La Definition of Done (DoD)

La Definition of Done est un engagement qualité de la Scrum Team. Elle garantit que chaque Incrément livré est vraiment terminé, conforme aux exigences de qualité et prêt à être utilisé ou livré. Elle peut inclure :

• Code développé et revu,

• Tests unitaires/passés,

• Documentation mise à jour,

• Intégration continue réalisée,

• Validation métier effectuée.

Tous les éléments sélectionnés dans un Sprint doivent respecter la DoD pour être inclus dans l’Incrément.

Qui peut la définir ?

L’équipe Scrum dans son ensemble, en particulier les développeurs.

Si l’organisation impose une norme de qualité, cette norme devient partie intégrante de la DoD.

En résumé :

La Definition of Done, c’est la checklist qualité de l’équipe Scrum. Elle permet de livrer des incréments vraiment terminés, partagés et sans ambiguïté. C’est une condition non négociable pour valider le travail comme fini.

La gestion du produit

Pour gérer au mieux le produit, le Product Owner doit mettre en place et définir certains éléments comme le Product Goal et les PBIs du Product Backlog, ici nous verrons le format des User Stories.

C'est la responsabilité du PO de maximiser la valeur du produit pour ses utilisateurs et clients et prioriser les éléments les plus importants.

Pour prioriser, on peut réaliser le ratio : Valeur / Complexité.

Pour définir la valeur, on peut utiliser la méthode de MoSCoW.

Product Goal

Le Product Goal (ou objectif produit) est l’engagement du Product Backlog.
Il donne une direction claire à l’équipe Scrum, en définissant ce que l’on veut atteindre à long terme avec le produit :

• C’est le fil rouge de tous les Sprints : chaque incrément nous rapproche du Product Goal.

• Il structure la roadmap produit,

• Il donne du sens à la priorisation des items du backlog.

Le Product Owner est responsable de définir et partager le Product Goal, L’équipe s’y réfère pour prendre des décisions et rester alignée.

Qu'est-ce qu'une User Story ?

Pour réaliser votre Example Mapping, on va choisir une User Story pour le faire. Mais qu'est-ce qu'une User Story ?

Créé dans Extreme Programming en 1999

Une fonctionnalité la plus minimale possible

Un support de validation du Product Owner et de l'utilisateur

Le format d'une User Story

Format :

 En tant que <qui>, je veux <quoi> afin de <pourquoi>.

Exemple :

 En tant que particulier, je veux chercher des artisans autour de   chez moi pour une intervention rapide.

Que je résume dans mes propres US sous le format :

Titre - Particulier cherche des artisans autour de sa position

Description - Pour une intervention plus rapide, un particulier va chercher les artisans qui sont le plus proche de la position qu'il a enregistré comme étant son logement.

Les critères d'acceptation

Les critères d'acceptation (AC) permet à l'équipe de savoir les critères spécifiques à une US pour être validée. Par exemple, lorsque vous réalisez une identification :

• L'User peut choisir entre la connexion avec e-mail ou compte Google.
• Un message d'erreur apparaît quand l'email n'est pas du bon format.
• L'User peut utiliser le lien "J'ai oublié mon mot de passe" pour récupérer son mot de passe.
• Un message d'erreur apparaît quand l'User n'a pas utilisé le bon mot de passe ou le bon email.

Qu'est-ce que MoSCoW ?

La méthode MoSCoW permet de catégoriser les exigences d’un projet selon leur niveau d’importance.
Le nom est un acronyme basé sur les premières lettres de chaque catégorie :

• Must have : Sans eux, le Sprint ou le produit ne peut pas être livré.
• Should have : Leur absence peut être inconfortable, mais le produit reste fonctionnel.
• Could have : Apportent de la valeur ajoutée ou un petit plus.
• Won’t have : Permet de garder une trace de ce qui a été écarté.

Création des groupes

8 personnes maximum, définissez qui aura le rôle du Product Owner, du Scrum Master et des Développeurs.

Trouvez un nom pour votre groupe !

Mise en relation entre particulier et artisan

Proposer toutes les prestations d'artisanats

Proposer les artisans proches du chantier

Arty, l'artisanat de demain.

Arty, l'artisanat de demain.

Le problème à résoudre :

Les particuliers qui ont besoin de réaliser des travaux ont du mal à trouver des artisans de confiance et leurs tarifs ; Cela peut conduire à des frais non prévus ou des dégâts quand l'artisan n'est pas professionnel.

Un système de recommendation

Un système de suggestion sur les critères du particulier

Offre détaillée de chaque artisan sur sa prestation

Arty, l'artisanat de demain.

Progresser rapidement grâce à des formations de seniors

Proposer toutes les catégories de formation professionnelle

Formation interactive avec exercices et corrections

Wisdom, devenir meilleur.

Wisdom, devenir meilleur.

Le problème à résoudre :

Les particuliers qui ont un plan de carrière difficile à atteindre ont du mal à monter en compétence quand ils sont isolés dans leur entreprise ; Cela ne leur permet pas de développer leurs compétences aussi vite qu'avec un senior dans leur équipe.

Un système d'éditeur de formation en ligne

Une IA qui réponds aux questions les plus posées ou redirige vers le senior

Notation des formations & recommendation

Wisdom, devenir meilleur.

Résoudre un escape game seul ou à plusieurs en VR de chez soi

Proposer les meilleurs escape games créés par des agences

Un système d'énigme et de mini-jeu poussé

Vscape, l'escape game chez soi.

Vscape, l'escape game chez soi.

Le problème à résoudre :

Les agences d'escape game ont du mal à avoir des revenues récurrents en fidélisant leurs joueurs ; La location de l'espace et du personnels est très coûteux et il n'y a pas beaucoup de re-jouabilité quand le joueur termine un escape game.

Un système d'éditeur d'escape game VR pour les agences

Un système de paiement par abonnement ou d'achat à l'unité

Notation des escape games & recommendation

Vscape, l'escape game chez soi.

Le client ne connaît pas son besoin

Attention, le client connaît son problème.

C'est à un expert de définir son besoin et sa solution.

Comment identifier les problématiques à résoudre ?

• Partez de la définition du problème du client. Ex: en partant du problème de Wisdom on peut en déduire la problématique suivante : "Comment rendre la recommandation pertinente ?".
• Les problématiques doivent être en rapport avec le problème du client, évitons les problématiques générales comme "Comment rendre l'interface érgonomique ?"
• N'hésitez pas à vous renseigner sur la logique métier. Cela représente le fonctionnement d'une activité du client.

Comment identifier les besoins utilisateurs ?

• Développez les besoins utilisateurs du point de vue d'un des personas. Ex: Pour Wisdom, on peut en déduire le besoin suivant "L'utilisateur doit pouvoir personnaliser ses recommendations".
• Mettez-vous à la place de vos personas, essayez de faire quelques scénarios en rapport avec le produit.

Comment identifier les opportunités ?

• Les opportunités surgissent durant le brainstorming, ce sont souvent des solutions pour raccourcir la charge de travail ou pour améliorer l'expérience utilisateur.
• Cela peut aussi être une chance d'être force de proposition face au client et d'innover.

Comment définir une activité ?

• Les activités découpent plus finement les besoins utilisateurs. Une activité est un grand groupe de fonctionnalités qui symbolise une tâche ou une action que doit réaliser l'utilisateur. Ex: 'Authentification' qui symbolise les fonctionnalités comme s'identifier ou s'inscrire.
• Le dialogue est très important avec le client, parfois on découvre des activités clés dans la conception de la solution qui n'était pas identifiée comme telle à la base. Ex: Facebook, l'activité clé est la publicité, on peut donc vite découvrir une activité clé qui sera la récupération des informations et comportements utilisateurs.

Comment trier et prioriser les activités ?

Vous devez trier les activités par ordre d'importance pour votre produit. Plusieurs techniques sont possibles, l'une d'entre elles priorisent les activités qui ont le meilleur ratio valeur / effort.

Ensuite, prioriser les activités dans plusieurs phases de développement du produit : la Preuve de concept, le Prototype et le Minimum Viable Product.

Comment définir les cas d'usages ?

• Posez-vous des questions, faites des hypothèses sur la résolution des problèmes ou la valeur que vous apportez à vos utilisateurs avec ce cas d'usage.
• N'allez pas trop loin, n'oubliez pas que vous devez d'abord faire une preuve de concept.
• Ne testez pas l'ergonomie de votre solution avant de valider le concept. Ex: "Est-ce que le bouton "S'inscrire avec Google" est bien placé ?" sera du travail obsolète si "Est-ce que l'utilisateur veut s'inscrire avec son compte Google pour gagner du temps ?" n'est pas valider en amont.

Les logiciels pour réaliser les sketchs ?

• Figma
• Whimiscal
• Miro
• Balsamiq
• Et beaucoup d'autres !

N'hésitez pas aussi à tout simplement utiliser un papier et un crayon ;-)

Comment réaliser un sketch ?

• Le but d'un sketch est d'être une représentation "Lo-fi" de votre solution finale. Le but ici est de gagner un maximum de temps pour être un support à l'idéation et la conception de votre solution.
• N'hésitez pas à définir des zones à l'écran comme "Présentation du produit" au lieu d'ajouter tous les détails, ceux-ci seront définis plus tard.
• Ici nous l'utilisons dans le cadre du "Zoning", une pratique qui permet via les cas d'usages de se rendre compte de la charge de travail et des fonctionnalités à produire en dessinant "à main levée".

Quel format ?

Si votre produit a de fortes chances d'être une application mobile, je vous conseille de partir sur une stratégie "Mobile-first". Cette stratégie prône le fait de faire en priorité les cas d'usages sur le format mobile pour ensuite adapté au format Desktop.

Quand on peut avec le moins, on peut avec le plus !

Règles pour l'atelier Scrum

Chaque itération dure 2 heures et comprend :

• Sprint Planning en 15 minutes
• Sprint en 1h15
• Sprint Review en 10 minutes
• Sprint Retrospective en 10 minutes
• Daily Scrum en 3/4 minutes
• Autres en fonction des besoins...

Le Daily Scrum est répété toutes les 20 minutes pendant le Sprint, pour favoriser l’alignement et l’auto-organisation.

Je serais présent en tant qu'Observateur ou Client en fonction du type de rituel, c'est au Scrum Master de m'appeler.

Règles pour l'atelier Scrum

Pendant les Sprints, des événements aléatoires peuvent survenir pour simuler la réalité du terrain :

• Le PO peut avoir une demande client surprise.

• Le PO peut recevoir un rapport UX ou Tech influant sur les priorités.

• Un développeur peut être bloqué techniquement et peut se réorienter temporairement (ex. : travailler sur la préparation de la soutenance finale).

N'oubliez pas de préparer la présentation pour la soutenance finale en fin de l'atelier. (Peut être une US dans le Backlog)

Quel outil pour Scrum ?

Pour vous aider durant le suivi de l'atelier, vous allez créer un compte Jira où vous allez être tous ensemble pour réaliser les différents rituels Scrum.

L'outil permet de réaliser un Product Backlog et de créer des Sprints.

C'est la responsabilité du Product Owner et du Scrum Master de mettre en place l'outil et de l'expliquer aux équipes.

(Pas de stress, la mise en place se fera au fur et à mesure)

Lien vers la CheatSheet pour Scrum Master