La Planification Agile: A Comprehensive Guide

METHODE AGILE Mansour DIEYE Authorized Training Partner Instructor PMP, PMP, PMI – ACP, MSP La o Livraison incrémentale o Définir la vision du projet PLANIFICATION o Structure de décomposition AGILE o Processus de plani...

METHODE AGILE Mansour DIEYE Authorized Training Partner Instructor PMP, PMP, PMI – ACP, MSP La o Livraison incrémentale o Définir la vision du projet PLANIFICATION o Structure de décomposition AGILE o Processus de planification AGILE o Ecrire les user story  1 LA PLANIFICATION ADAPTATIVE Comme nous l'avons vu tout au long, les méthodes agiles sont axées sur la valeur. C'est la raison pour laquelle le backlog est priorisé en plaçant en tête de liste les éléments à forte valeur ajoutée. Dans le cadre de cette focalisation sur la création de valeur, les méthodes agiles tentent également de minimiser tout travail n'apportant pas de valeur ajoutée. Étant donné que les activités de planification n'ajoutent pas directement de la valeur, elles peuvent être considérées comme du gaspillage.  1 LA PLANIFICATION ADAPTATIVE Ainsi, pour minimiser le gaspillage, on pourrait penser que planifier le projet de manière exhaustive et ne pas y revenir par la suite semble être la méthode la plus optimale. Malheureusement, cette approche n'est pas efficace pour les projets de travail indéfinissable en raison de leur taux élevé de changement. C’est pourquoi l'approche agile adopte une planification adaptative. La planification adaptative est une approche de gestion de projet qui privilégie la flexibilité et l'adaptation continue tout au long du cycle de vie du projet. La planification adaptative reconnaît que les projets évoluent et que de nouvelles informations émergent au fur et à mesure de leur avancement.  1 LA PLANIFICATION ADAPTATIVE Dans les méthodologies Agile, comme Scrum, le travail est organisé en sprint. Chaque sprint aboutit à un livrable fonctionnel qui peut être amélioré et enrichi dans les sprints suivants. Cette approche contraste nettement avec les projets en cascade, où un seul produit final est livré à la fin du développement. Livraison incrémentale Pour illustrer la différence, imaginez que vous engagez une équipe pour créer un potager avec trois jardinières, chacune plantée de tomates, de poivrons et de courgettes. Chaque jardinière nécessite de la terre, de l'engrais et des graines. Vous recevez des propositions de deux équipes de jardinage pour vous assister dans ce projet. Poivron Tomate Courgette Equipe 1 Dans la première phase, l'équipe 1 qui a une approche Waterfall, remplit les 3 jardinières de terre. Poivron Tomate Courgette Equipe 1 Dans la phase 2, l’ équipe Waterfall ajoute l'engrais approprié Poivron Tomate Courgette Equipe 1 et enfin dans la phase 3, l’ équipe Waterfall ensemence les trois jardinières. Poivron Tomate Courgette Equipe 2 La deuxième équipe, adoptant une approche agile, compte faire le travail en trois sprints. Dans le premier sprint, elle s’engage a vous livrer de la valeur. Puisque la tomate est votre légume préféré, elle sera plantée en premier. Courgette Poivron Tomate Sprint 1 Equipe 2 Pour le deuxième sprint, le poivron étant votre deuxième légume préféré, alors l’ équipe Agile ajoute de la terre, de l'engrais et des semences de poivron dans le deuxième bac. Tomate Poivron Courgette Sprint 1 Sprint 2 Equipe 2 Pour le troisième sprint, la courgette étant votre troisième légume préféré, alors l’ équipe Agile ajoute de la terre, de l'engrais et des semences de courgette dans le troisième bac. Tomate Poivron Courgette Sprint 1 Sprint 2 Sprint 3  Réflexion o Quels sont les avantages et inconvénients de chaque approche? o Si au bout de quelques semaines, vous n’avez plus d’argent pour continuer le projet, quels serait les avantages ou inconvénients de chaque approche?  Réflexion WATERFALL AGILE Approche claire avec une planification détaillée dès le Moins de visibilité globale sur le projet dès le départ. départ. Manque de flexibilité, difficile de s'adapter à des Flexibilité avec la possibilité d’ajuster la stratégie en changements une fois la planification terminée. cours du projet. La valeur n'est obtenue qu'à la fin du projet. Livraison progressive de valeur avec possibilité d’avoir des résultats exploitables à chaque sprint. Si le budget est coupé avant la fin de la dernière Si le budget est coupé avant la fin du dernier sprint, phase, le travail réalisé ne produira aucune valeur Par exemple, après le deuxième sprint, les jardinières concrète. L'absence de livraisons progressives rend de tomates et de poivrons seront fonctionnelles et cette approche vulnérable à l'interruption de commenceront à produire. L’avantage réside donc financement. dans la livraison progressive de valeur et la flexibilité pour ajuster le projet en fonction des contraintes.  2 Qu’est ce que la vision du produit La vision de produit est une explication du produit, de ses clients cibles et de la manière dont leurs besoins seront satisfaits. Elle sert de déclaration claire et concise qui décrit l'état futur souhaité d'un produit, en décrivant le but et les objectifs du produit, ainsi que le public cible et les avantages que le produit leur apportera. La vision du produit doit être revisitée et affinée tout au long du projet à mesure que de nouvelles informations deviennent disponibles.  3 Le processus d’élaboration de la vision du produit Le processus d’élaboration de la vision du produit peut être défini comme suit: 1. Comprendre le But : Quel problème ou besoin adresse-t-il ? Pourquoi est-il précieux pour les clients ou utilisateurs ? 2. Définir l'Objectif : Articulez clairement l'objectif global ou l'objectif du produit. 3. Identifier le Public Cible : Déterminez qui sont les utilisateurs et bien comprendre leurs besoins et préférences. 4. Proposition de Valeur : En quoi ce produit se distingue-t-il de la concurrence ? Quels sont les avantages et les bénéfices qu'il apporte aux utilisateurs ? 5. Formuler la déclaration de vision du produit : Formuler la vision du produit sous la forme d'une déclaration concise, facile à retenir et à comprendre pour tous les acteurs du projet.  4 Exemple de Vision du produit Éléments clés But: transformer l'expérience de la gestion des tâches et améliorer la collaboration au sein des équipes. Objectif: Devenir la solution préférée pour améliorer la productivité et la transparence des projets. Proposition de valeur: Organisation efficace des tâches, suivi de la progression en temps réel et communication transparente au sein de l'équipe. Différenciation: Technologie de pointe et expérience utilisateur intuitive adaptée aux flux de travail de l'équipe. Impact: Amélioration de la productivité, de la transparence des projets et de la collaboration entre les membres de l'équipe. 4 Exemple de Vision du produit Notre vision est de développer une application de gestion des tâches de pointe qui transforme la façon dont les équipes collaborent et gèrent les projets. Cette application permettra aux utilisateurs d'organiser efficacement les tâches, de suivre les progrès en temps réel et de favoriser une communication transparente au sein des équipes distribuées. Notre objectif est de devenir la solution de référence pour les équipes qui cherchent à améliorer la productivité, la transparence et la collaboration dans le cadre de leurs projets 5 Principes de la planification agile Planifier à plusieurs niveaux Impliquer l'équipe et le client dans la Planifier à planification plusieurs niveaux Gérer les attentes en démontrant fréquemment les Utiliser des fourchettes d'estimation appropriées pour refléter le niveau d'incertitude progrès et en extrapolant la Utiliser des vélocité fourchettes d'estimation appropriées Quelques principes clés pour refléter le niveau de la planification agile d'incertitude Adapter les processus aux spécificités du Prendre en compte les risques, les distractions et de la disponibilité de l'équipe dans les estimations projet Prendre en Mettre à jour le plan en fonction des priorités du projet compte les risques, les Mettre à distractions et jour le plan de la en fonction disponibilité de des priorités l'équipe dans les du projet estimations  En Agile, Planifier à plusieurs niveaux signifie décomposer le processus de planification en différentes étapes, chacune avec un niveau de détail spécifique. o Au début du projet, nous définissons la situation dans son ensemble, c'est-à- dire ce que nous voulons accomplir et ce que signifie Terminé pour l'ensemble du projet. Cela permet de définir l'orientation et la vision du projet. Planifier à o Ensuite, nous divisons le projet en parties plus petites et plus faciles à gérer, appelées Releases ou Version Chaque version comprend un ensemble de plusieurs caractéristiques ou de fonctionnalités. Nous planifions la date à laquelle nous niveaux prévoyons de livrer chaque version, ce qui permet d'établir une feuille de route globale pour l'avancement du projet. o Enfin, nous planifions les itérations ou sprint : Il s'agit du niveau de planification le plus détaillé. Pour chaque itération, nous décidons des user stories sur lesquelles l'équipe travaillera, et nous les décomposons en tâches plus petites que l'équipe peut accomplir au cours de l'itération.  Dans la méthode Agile, Impliquer l'équipe et le client dans la planification est essentiel car cela permet de créer un processus mieux informé et plus collaboratif. Voici pourquoi c'est important : o Le chef de projet ne dispose pas toujours de toutes les informations nécessaires pour répondre aux besoins du client. En impliquant l'équipe, vous tirez profit de leurs Impliquer connaissances techniques et de leurs points de vue, pour garantir que le plan est l'équipe et le précis et réaliste. client dans la o L'implication du client dans la planification permet de répondre directement à ses planification besoins et à ses attentes. Cela permet d'aligner le travail de l'équipe sur la vision et les priorités du client. o Lorsque l'équipe est impliquée dans le processus de planification, elle s'approprie le plan. Cela accroît leur engagement et leur motivation à tenir leurs engagements, car ils ont contribué à le créer.  Dans la méthode Agile, Gérer les attentes en démontrant fréquemment les progrès et en extrapolant la vélocité, est essentielle pour tenir les parties prenantes informées et Gérer les alignées sur la réalité du projet. attentes en o Les équipes agiles montrent régulièrement aux parties prenantes ce qui a été construit démontrant à la fin de chaque itération (revue de sprint ou démo). Les parties prenantes peuvent fréquemment voir exactement ce qui est livré, ce qui permet de gérer les attentes concernant les les progrès et en résultats et le calendrier du projet. extrapolant la o Au lieu de s'appuyer sur des plans optimistes, les équipes agiles utilisent des données vélocité réelles - la vitesse à laquelle l'équipe a accompli son travail (vélocité) - pour faire des projections. En examinant le rythme de travail actuel, l'équipe peut fournir des estimations réalistes de la date d'achèvement du projet et de son coût.  Dans la méthode Agile, Adapter les processus aux spécificités du projet, signifie ajuster la planification et l'exécution en fonction des besoins spécifiques du projet. Voici comment cela fonctionne : o Les grands projets nécessitent généralement une planification plus détaillée pour gérer leur complexité, tandis que les petits projets peuvent souvent être planifiés plus Adapter les simplement et de manière itérative. processus aux o Si les exigences et la technologie du projet sont bien comprises, il est logique d'investir spécificités du plus de temps dans la planification initiale, car les risques sont moindres. Vous pouvez projet planifier le travail à venir en toute confiance, car il y a moins d'incertitudes. o Si le projet comporte des inconnues, telles que de nouvelles technologies ou des exigences floues, l'équipe doit planifier en pics (spikes). Un pic est une série d'activités exploratoires de courte durée au cours desquelles l'équipe étudie des solutions, vérifie des hypothèses ou expérimente des technologies afin de réduire l'incertitude. Cela permet à l'équipe de rassembler des informations avant de s'engager dans une démarche de mise en œuvre complète.  Dans la méthode Agile, mettre à jour le plan en fonction des priorités du projet est essentiel pour s'assurer que le projet produise les résultats les plus utiles. Voici comment cela fonctionne : o L'entreprise, représentée par le propriétaire du produit, définit les priorités en fonction Mettre à jour le des besoins de l'organisation. Ces priorités se reflètent dans le backlog, que le plan en propriétaire du produit et l'équipe de développement tiennent à jour. fonction des priorités du o Lorsque qu'il y a de nouvelles informations ou des changements, par exemple un changement d'orientation du projet, l'équipe doit réévaluer le backlog et le plan de projet release. Cela garantit que le travail le plus important est réalisé en premier et qu'il s'aligne sur les nouvelles priorités. Par exemple: Si la version anglaise d'un site web devient la priorité absolue, l'équipe devra peut-être retarder ou ajuster les tâches liées à l'internationalisation ou à la traduction. L'objectif est de se concentrer sur ce que l'entreprise valorise le plus à un moment donné.  Dans la méthode Agile, Prendre en compte les risques, les distractions et de la disponibilité de l'équipe dans les estimations consiste à créer des calendriers de projet réalistes qui ne se limitent pas à des conditions de travail idéales. Voici comment cela fonctionne : o Les commanditaires veulent naturellement savoir quand le travail sera terminé, Prendre en compte mais les estimations qui ne tiennent pas compte des risques potentiels ou des les risques, les distractions peuvent conduire à des échéances irréalistes et à des attentes non distractions et de la satisfaites. disponibilité de l'équipe dans les o Les équipes agiles commencent par examiner les données historiques, telles que les tendances passées en matière de vélocité, afin d'obtenir une compréhension estimations de base de la quantité de travail qui peut être réalisée dans un délai donné. o Les équipes ajustent ensuite ces estimations en tenant compte de la disponibilité future de l'équipe (congés, vacances ou absences), des distractions potentielles (réunions, autres projets) et des risques (problèmes ou défis inattendus). Ces facteurs ont inévitablement un impact sur la capacité de l'équipe à fournir le travail dans les délais.  Utiliser des fourchettes d'estimation appropriées pour refléter le niveau d'incertitude permet de gérer les attentes en fournissant des estimations qui correspondent à la complexité et à l'incertitude de la tâche. Voici comment cela fonctionne : o Lorsque l'objectif est à court terme et bien compris, l'équipe peut fournir une Utiliser des fourchettes fourchette d'estimation étroite pour les tâches bien connues. Par exemple, si une d'estimation appropriées tâche est routinière et qu'il y a peu de risques de surprises, une fourchette étroite pour refléter le niveau comme 15 à 20 minutes est appropriée. d'incertitude o Lorsqu'il y a plus d'incertitude, comme dans le cas de tâches complexes ou de délais plus longs, il est important de fournir une fourchette plus large. Cela permet de tenir compte des facteurs inconnus qui pourraient survenir. Par exemple, une tâche peut prendre 5 à 8 jours en raison de facteurs imprévisibles tels que la disponibilité ou des retards inattendus.  6 Élaboration progressive L'élaboration progressive dans la méthode Agile fait référence à la pratique consistant à ajouter progressivement plus de détails à divers éléments du projet au fur et à mesure que l'équipe en apprend davantage au fil du temps. Les équipes agiles ne cherchent pas à avoir des plans détaillés dès le départ ; au lieu de cela, elles commencent par des concepts généraux et les affinent continuellement au fur et à mesure que de nouvelles informations sont disponibles. Au début d'un projet, l'équipe doit dimensionner et estimer le travail afin d'évaluer la portée du projet et de développer une stratégie d'exécution raisonnable. Cependant, c'est aussi la phase où l'équipe en sait le moins sur le projet, car il n'y a pas encore eu d'expérience pratique ou d'apprentissage par la pratique. En raison de cette incertitude, il ne serait pas judicieux de se baser uniquement sur les plans et les estimations initiaux. Au contraire, les équipes Agile affinent continuellement les plans et les estimations tout au long du projet pendant qu'elles acquièrent des connaissances et de l'expérience. Au fur et à mesure que le projet progresse, de nouveaux détails apparaissent, ce qui permet à l'équipe d'ajuster en connaissance de cause son approche, son calendrier et l'affectation de ses ressources. Ce processus continu de mise à jour et d'amélioration des plans est appelé élaboration progressive. Il garantit que le projet reste flexible et adaptable, ce qui permet d'obtenir des résultats plus précis et plus réalistes au fil du temps.  6 Élaboration progressive Le concept d'élaboration progressive est illustré dans les 2 figures suivantes. Dans le premier diagramme ci- dessous, la flèche "Maintenant" indique que nous sommes au début du projet et que nous créons les plans initiaux. Les lignes diagonales des premières itérations indiquent le niveau de détail de nos plans pour ces itérations. Comme vous pouvez le constater, à ce stade, la première itération a été planifiée de manière très détaillée, mais les itérations suivantes ont été planifiées de manière de moins en moins détaillée. Planification en Plan de Release amont 80% à 85% de l’échéancier 10%-15% de Clôture l’échéancier 5% de l’échéancier Maintenant Itérations  6 Élaboration progressive Le diagramme suivant montre comment nous élaborons progressivement nos plans et ajoutons des détails au fur et à mesure que le projet avance et que de nouvelles informations apparaissent. Ici, la flèche Maintenant indique que nous en sommes à la deuxième itération. À ce stade, la troisième itération a été planifiée en détail, tandis que le plan de la 4e, 5e et 6e sont de moins en moins détaillés. Ce processus d'affinement de notre plan à mesure que nous nous rapprochons d'une itération se poursuit tout au long du projet. Plan de Release 80% à 85% de l’échéancier Clôture Planification en amont 5% de l’échéancier 10%-15% de l’échéancier Maintenant Itérations  7 Analyse basée sur la valeur Dans la planification Agile, l'analyse basée sur la valeur implique l'évaluation continue et la hiérarchisation de la valeur commerciale des éléments de travail tout au long du cycle de vie du projet. Ce processus influence la manière dont nous définissons le périmètre, planifions, programmons, développons, testons et faisons les releases. À chaque étape, l'équipe se pose les questions suivantes : o Quelle est la valeur commerciale de cet élément ? o Quels éléments offrent la plus grande valeur ?  7 Analyse basée sur la valeur Toutefois, il est important d'examiner non seulement la valeur commerciale, mais aussi le coût de développement. Par exemple, une fonctionnalité qui génère une valeur commerciale de $5 000 mais dont le développement coûte $4 000 peut avoir moins de valeur qu'une fonctionnalité qui en génère $3 000 mais qui ne coûte que $1 000. Pour évaluer cela, les équipes Agile créent des estimations de haut niveau dès le début du projet, ce qui leur permet de faire des comparaisons coûts-avantages. Cela permet au client de hiérarchiser les éléments en fonction de la valeur qu'ils apportent par rapport à leur coût. $ 5000 Valeur $3 000 commerciale Valeur commerciale  7 Analyse basée sur la valeur Par conséquent, lorsque nous évaluons la valeur d'un élément de travail, nous devons tenir compte de son coût de développement probable. Pour ce faire, les équipes agiles créeront des estimations de haut niveau des éléments du backlog dès le début du projet. Cela leur permet d'effectuer des comparaisons de valeur coût-bénéfice que le client peut utiliser pour hiérarchiser les éléments à développer. Par exemple, pour maximiser la valeur de la prochaine version, l'équipe peut prévoir, avec l'accord du client, de réaliser plusieurs fonctionnalités de valeur moyenne qu'elle peut développer rapidement plutôt qu'un élément de plus grande valeur qui consommerait tout le temps de développement restant. Backlog du produit Liste des hiérarchisé fonctionnalités Ateliers d'analyse candidates basée sur la valeur des fonctionnalités Fonctionnalités du produit 1. 2. Backlog du 3. sprint 4. 5. P  7 Analyse basée sur la valeur 2 autres facteurs méritent d'être considérés : la fréquence des retours sur investissement et les dépendances : o La fréquence des retours sur investissement : Déterminez si l'élément de travail apportera une valeur commerciale continue (comme un gain de temps pour le personnel, une valeur ajoutée chaque semaine ou chaque mois) ou s'il apporte une valeur ponctuelle (comme un contrôle de conformité). Pour avoir une vue d'ensemble, il est important d'examiner le retour potentiel sur une période plus longue, par exemple de 1 à 5 ans, afin d'évaluer pleinement sa valeur commerciale. o Dépendances : Il arrive qu'une fonctionnalité à forte valeur ajoutée dépende de l'achèvement préalable d'une fonctionnalité de moindre valeur. Dans ce cas, l'équipe doit terminer l'élément à faible valeur avant de pouvoir livrer l'élément à forte valeur en vue de libérer tout son potentiel commercial. Backlog du produit Liste des hiérarchisé fonctionnalités Ateliers d'analyse candidates basée sur la valeur des fonctionnalités Fonctionnalités du produit 1. 2. Backlo 3. spr 4. 5.  8 Décomposition basée sur la valeur La décomposition basée sur la valeur est l'étape suivante de l'analyse basée sur la valeur dans la méthode Agile. Voici comment elle fonctionne : 1. L'équipe recueille les exigences directement auprès des parties prenantes afin de comprendre les besoins. 2. L'équipe organise et décompose ces exigences de haut niveau en plus petit éléments ou fonctionnalités gérables. 3. Les exigences les plus prioritaires, basées sur la valeur, sont ensuite intégrées dans le cycle de développement. Backlog du produit Planifier hiérarchisé és Apprendre Développer Incréments de nouvelles fonctionnalités Backlog du Évaluer sprint Décomposer les fonctionnalités en stories, Développer les stories Présenter les stories sous forme de fonctionnalités. Obtenir des feedbacks organiser des rétrospectives  9 Le Timebox ou boite de temps Dans la méthode Agile, le Timebox est un concept fondamental qui aide les équipes à rester flexibles et focalisées sur leurs objectifs. Un Timebox est une période fixe, telle qu'un sprint ou une itération, au cours de laquelle l'équipe s'engage à accomplir un ensemble spécifique de tâches. Ce délai est non négociable. Si le travail prévu dans le timebox n'est pas achevé à la fin du temps imparti, l'équipe arrête de travailler et déplace simplement le travail inachevé dans un autre timebox.  9 Le Timebox ou boite de temps Le timeboxing est étroitement lié au Triangle de la triple Contraintes (temps, coût et portée). La méthode Agile fixe le temps grâce au timebox (comme les sprints) et le coût en maintenant la taille de l'équipe et le budget constants. La portée reste cependant flexible, permettant à l'équipe d'ajuster le travail à accomplir dans chaque timebox. La méthode agile déplace le focus sur le contrôle rigide de la portée vers l'adaptabilité et la livraison continue. Portée Coût Durée FIXE AGILE WATERFALL VARIABLE  9 Le Timebox ou boite de temps La différence entre le triangle de la triple contrainte dans les approches Waterfall et Agile réside principalement dans la manière dont sont gérés les aspects de portée, de temps et de coût et de focus. Aspect Triangle Agile Triangle Waterfall Temps Fixe avec le timebox (par exemple, les sprints Variable, il peut être ajusté en fonction des ou les itérations). besoins pour compléter l'ensemble de la portée. Coût Fixe sur la base de la taille de l'équipe et du Variable, il peut augmenter si la portée exige budget pour chaque timebox. plus de temps ou de ressources. Portée Variable, il est adapté pour pouvoir être réalisé Fixe, toutes les exigences définies doivent être dans le timebox et les coûts fixés. satisfaites avant la fin du projet. Focus Il donne la priorité à la livraison des Il se concentre sur la réalisation de toutes les fonctionnalités à plus forte valeur ajoutée, en exigences prévues, même si cela nécessite une ajustant la portée si nécessaire pour respecter prolongation des délais ou des coûts. les contraintes de temps et de coût.  9 Le Timebox ou boite de temps Le Timebox agile peut durer de quelques minutes à quelques semaines. Par exemple: o Les Daily Stand Up sont limitées à 15 minutes. o Les rétrospectives ont souvent une durée de 2 heures. o Les itérations et les sprints ont généralement une durée de 1 à 4 semaines.  9 Le Timebox ou boite de temps Explorons un peu plus avant le concept de Timebox. Imaginons qu'une équipe prévoit de terminer 10 éléments de travail au cours d'une itération, mais qu'à la fin du délai, elle n'en a terminé que 8. Même si elle n'a pas terminé tous les éléments de travail prévus, elle ne prolonge pas le délai de l’ itération pour terminer le travail. Au lieu de cela, ils signalent que 8 éléments ont été achevés et renvoient les 2 éléments restants dans le backlog pour qu'ils soient pris en charge lors de la planification de la prochaine itération. Le Timebox permet d'apporter un certain niveau d'ordre et de cohérence dans un environnement de travail très changeant. C'est la raison pour laquelle le Timebox est souvent appelé le contrôle dans le chaos.  9 Le Timebox ou boite de temps Une autre façon de comprendre le concept de Timebox Une autre façon de comprendre le concept d'itération dans le temps est d'imaginer une boîte qui représente la capacité de travail de l'équipe.  9 Le Timebox ou boite de temps L'équipe charge les éléments de travail (user stories) dans la boîte par ordre de priorité. Si tous les éléments ne rentrent pas dans la boîte - en d'autres termes, si l'équipe n'a pas la capacité de terminer tout le travail au cours de l'itération - l'élément de priorité la plus faible devra attendre. Il sera remis dans le backlog et pris en compte dans la planification des itérations suivantes.  9 Le Timebox ou boite de temps Le timebox peut être un outil efficace pour se concentrer sur une tâche précise. Par exemple, certaines personnes utilisent la technique Pomodoro, qui consiste à travailler pendant 25 minutes, puis à prendre une courte pause. Cela permet de faire 2 sessions de travail par heure, avec du temps entre les sessions pour vérifier les e-mails ou se détendre. Cette méthode est efficace car elle réduit les distractions et le multitâche inefficace. En se concentrant pendant 25 minutes sans interruptions, on travaille de manière plus productive, avant de faire une pause de 10 minutes.  10 Estimation des projets agiles Les estimations de projets agiles présentent d'importantes similitudes et différences avec les estimations de projets traditionnels, non itératifs. Par exemple, au début d'un projet agile, alors que nous en savons le moins sur le projet, nos techniques d'estimation sont assez similaires aux méthodes d'estimation traditionnelles. Nous appliquons des approches heuristiques (fondées sur les connaissances des experts), par exemple en examinant les données de projets qui ont créé des produits similaires ou dont la taille et la complexité étaient à peu près les mêmes, afin de déterminer la durée de ces projets. Nous pouvons également procéder à des estimations paramétriques (basées sur des calculs), telles que les estimations bottom-up. Les estimations bottom-up en Agile consistent à diviser le projet en user stories individuelles, à estimer l'effort requis pour chacune en fonction de sa taille et complexité, puis à additionner ces estimations.  10 Estimation des projets agiles Les projets agiles sont généralement plus difficiles à estimer que les projets traditionnels parce qu'ils impliquent souvent complexité et incertitude, comme l'utilisation d'une nouvelle technologie. Cette incertitude fait qu'il est plus difficile de fournir des estimations précises pour ces types de projets. Pour y remédier, les équipes Agile évitent de donner des estimations ponctuelles (un chiffre précis). Au lieu de cela, elles fournissent des estimations en fourchettes afin de refléter le niveau d'incertitude et de fixer des attentes réalistes avec les parties prenantes. Par exemple, au lieu de dire Ce projet coûtera exactement $784 375,32, ce qui implique un haut niveau de précision, elles peuvent dire Nous estimons que le projet coûtera entre $775 000 et $825 000. La largeur de la fourchette reflète la confiance de l'équipe dans l'estimation. Une fourchette étroite signifie que l'équipe est relativement confiante dans l'estimation, tandis qu'une fourchette plus large indique une plus grande incertitude. Temps idéal et Temps probable Le temps idéal consiste à estimer le temps que prendrait une tâche sans interruption ni distraction. Lorsqu'on demande à une équipe d'estimer son travail, des facteurs tels que les réunions, les e-mails et autres sont souvent à prendre en compte. Plutôt que d'ajuster l'estimation pour tenir compte de ces activités, l’équipe agile suppose qu'une journée de travail de 8 heures est entièrement consacrée à la tâche à accomplir, sans distraction ni tâche extérieure. Bien que cela ne corresponde pas à la réalité, l'estimation en temps idéal permet à l'équipe de se concentrer sur l’effort réel nécessaire pour accomplir la tâche sans se soucier de variables telles que la disponibilité ou les interruptions. Ce type d'estimation nous indique combien de temps le travail prendrait dans des conditions parfaites, où la tâche est le seul objectif, où il n'y a pas de retard et où toutes les ressources ou informations nécessaires sont immédiatement disponibles. Ce type d'estimation simplifie le processus d'estimation et donne une image plus claire de l'effort requis. Temps idéal et Temps probable Le temps probable fait référence au temps réaliste qu'il faudra pour achever une tâche, en tenant compte des interruptions potentielles, des distractions et des variations de productivité. Contrairement au temps idéal, qui ne prévoit aucune perturbation, le temps probable tient compte de facteurs tels que les réunions, les pauses ou les retards inattendus, ce qui en fait une estimation plus pratique à des fins de planification. EXEMPLE Supposons qu'après avoir dormi et effectué les activités essentielles telles que se laver, préparer les repas et manger, il vous reste 12 heures disponibles dans votre journée. Supposons maintenant que vous avez besoin de 60 heures pour vous préparer à la certification Agile. À l'aide de ces informations, calculez la durée idéale et la durée probable de l'étude de l'examen. Temps idéal Si la préparation de l'examen prend théoriquement 60 h et que nous disposons de 12 h par jour, Il nous faut alors 5 jours pour nous préparer à la certification. Le temps idéal peut être calculé comme suit : 60h / 12h = 5j EXEMPLE Temps probable Pour estimer le temps probable, nous devons surement prendre en compte d'autres facteurs, comme le travail et la famille, et le fait qu'il y a des nuits où nous rentrons à la maison et sommes trop fatigués pour penser à quoi que ce soit. Il est peut-être plus réaliste de supposer qu'en moyenne, nous consacrons 4 h/semaine à la préparation de l'examen. À ce rythme, il nous faudra donc 15 semaines de préparation. 60h / 4h = 15 sem. EXEMPLE Cet exercice met en évidence un autre point à prendre en considération : l'efficacité du calendrier. Même si nous disposions de 12 heures par jour pendant 5 jours, nous ne serions pas en mesure de retenir ou d'absorber efficacement toutes les informations pendant cette période. Par conséquent, étudier sur une période plus longue peut non seulement être plus réaliste, mais dans cet exemple, c'est aussi probablement plus efficace. De la même manière, nous devons veiller à ce que le délai ne soit pas trop long, afin d'éviter le problème de la fuite des connaissances, c'est-à-dire le déclin progressif des connaissances que nous n'utilisons pas tous les jours. Si un délai trop court peut poser un problème, il en va de même pour un processus trop lent  11 Dimensionnement, Estimation et Planification Nous avons dit que la planification agile est basée sur 3 hypothèses. o Les détails apparaîtront au fur et à mesure de l'avancement du projet. o Nous devrons adapter notre plan en fonction du retour d'information. o Nous devons redéfinir les priorités en fonction de l'évolution des besoins de l'entreprise. Cela signifie que les équipes agiles embrassent le changement et l'incertitude. Cette acceptation est au cœur de la planification agile. L'objectif est d'utiliser des outils et des techniques assez flexibles pour s'adapter à l'évolution du projet et faire en sorte que l'équipe puisse réagir en permanence aux nouvelles informations. Dans cette section, nous examinons les outils et techniques spécifiques que les équipes agiles utilisent pour la planification adaptative. Nous commencerons par expliquer comment le dimensionnement et l'estimation s'intègrent dans le processus de planification, puis nous discuterons des outils utilisés pour décomposer les exigences et estimer les éléments de travail. 11 Dimensionnement, Estimation et Planification le processus de planification agile est décomposé en 3 étapes : Dimensionnement Estimation Panification En combien de temps Quand peut-on le Quelle est sa taille ? peut-on le faire? faire ?  Dimensionnement Estimation Panification Quelle est sa taille ? En combien de temps Quand peut-on le peut-on le faire? faire ? Dimensionnement : Il s'agit de la première étape, au cours de laquelle l'équipe détermine la taille ou la portée du travail. L'équipe doit comprendre l'ampleur de la tâche ou de la fonctionnalité sur laquelle elle travaille avant de passer aux étapes suivantes. Estimation : l'équipe estime ensuite le temps ou l'effort nécessaire pour l'accomplir. Il s'agit de déterminer la vitesse à laquelle l'équipe peut travailler, sur la base des performances passées et de la capacité de l'équipe. Planification : Enfin, l'équipe planifie le moment où elle pourra livrer le travail, en tenant compte de la disponibilité des membres de l'équipe, des risques potentiels et autres facteurs. 12 Décomposition des exigences Aborder un projet dans son entièreté peut s'avérer extrêmement complexe, ce qui le rend difficile à dimensionner, à estimer ou à planifier efficacement. Pour y parvenir, nous devons trouver un moyen de décomposer les exigences du projet en éléments plus petits et plus détaillés. Ce processus se poursuit jusqu'à ce que chaque élément du projet devienne suffisamment petite pour être estimée et planifiée sans difficulté. Dans les projets Agile, cette approche est connue sous le nom de décomposition des exigences, et elle est mise en œuvre par le biais d'une planification itérative. 12 Décomposition des exigences Une hiérarchie de base des exigences pour un projet agile comporte trois niveaux, comme indiqué ci-dessous Fonctionnalité Fonctionnalité Fonctionnalité User Story User Story User Story Tâche 1 Tâche 2 Tâche 3 12 Décomposition des exigences Bien qu'il n'y ait pas une seule façon de structurer la hiérarchie des exigences, ce diagramme illustre l'approche la plus simple. Ici, les fonctionnalités du produit sont d'abord décomposées en plus petites parties user stories. Ensuite, au fur et à mesure que l'équipe affine son plan, elle décompose les user stories en éléments plus petits, appelés tâches. Fonctionnalité User Story User Story Tâche 1 Tâche 2  12 Décomposition des exigences Cependant, certaines équipes élargissent ce modèle de base en ajoutant des épopées. Une épopée est un ensemble de travaux de haut niveau qui représente un vaste objectif ou une fonctionnalité trop importante pour être achevée en un seul sprint. Elle est généralement décomposée en plusieurs user stories, plus petites et plus faciles à gérer, qui peuvent être développées en plusieurs itérations. Fonctionnalité Epopée User Story User Story Tâche 1 Tâche 2  12 Décomposition des exigences Un exemple simple d'épopée pourrait être Développer une interface de login pour les utilisateurs pour un site web. Cette épopée, trop grande pour un seul sprint, est décomposée en user stories plus petites, qui peuvent être réalisées individuellement sur plusieurs sprints. Cette épopée peut être décomposée en user stories plus petites, telles que: o En tant qu'utilisateur, je veux pouvoir m'inscrire avec mon adresse e-mail et un mot de passe, afin de créer un compte personnel sécurisé o En tant qu'utilisateur, je veux pouvoir demander une réinitialisation de mon mot de passe si je l'oublie, afin de pouvoir réaccéder à mon compte. o En tant qu'utilisateur, je veux pouvoir me connecter à mon compte en utilisant mon compte Google, afin de simplifier le processus de connexion. Fonctionnalité Epopée User Story User Story  12 Décomposition des exigences Les exigences du projet sont décomposées JIT, Just In time ou Juste à temps ou au dernier moment opportun. Au fur et à mesure que l'équipe se rapproche de l'exécution du travail, les fonctionnalités sont progressivement affinées en user stories, puis en éléments de travail plus détaillés, tels que les tâches, les tests d'acceptation, etc. Décomposition des exigences JIT Fonctionnalité Tâches User Story Règles User Story Test Diagramme Test d'acceptation  13 Les User Stories Dans la méthode Agile, l'un des principaux outils de planification est la User Story. Une user story est un petit élément bien défini d'une fonctionnalité métier qui apporte de la valeur à l'utilisateur final. La durée d'une user story est généralement estimée entre 1 et 3 jours de travail pour l'équipe. Certaines équipes peuvent définir une fourchette plus précise, par exemple de 4 à 40 heures. Ce dimensionnement permet à l'équipe de s'assurer que chaque user story est suffisamment petite pour être exécutée au cours d'un sprint, mais assez grande pour permettre de réaliser des progrès significatifs.  13 Les User Stories Une user story se compose généralement de trois éléments principaux : le rôle, l'objectif, et la raison. Composant Description Exemple User Story Complète Il s'agit de la personne ou du groupe qui a besoin Rôle de la fonctionnalité. Le rôle permet de comprendre En tant que client, pour qui la fonctionnalité est développée. User Story 1 En tant que client, je je veux pouvoir L’objectif est l’action ou la tâche que l'utilisateur veux pouvoir suivre suivre mes Objectif souhaite accomplir. Ici, le client veut pouvoir suivre mes commandes en commandes en ses commandes en ligne. ligne pour savoir ligne quand mon colis Cela explique pourquoi l'utilisateur a cet objectif, arrive c'est-à-dire la motivation ou le bénéfice qu'il en pour savoir quand Raison tire. Dans ce cas, le client veut suivre ses mon colis arrive. commandes pour savoir quand son colis arrive.  13 Les User Stories Une user story se compose généralement de trois éléments principaux : le rôle, l'objectif, et la raison. Composant Description Exemple User Story Complète Il s'agit de la personne ou du groupe qui a besoin Rôle de la fonctionnalité. Le rôle permet de comprendre En tant que client, pour qui la fonctionnalité est développée. User Story 1 En tant que client, je je veux pouvoir L’objectif est l’action ou la tâche que l'utilisateur veux pouvoir suivre suivre mes Objectif souhaite accomplir. Ici, le client veut pouvoir suivre mes commandes en commandes en ses commandes en ligne. ligne pour savoir ligne quand mon colis Cela explique pourquoi l'utilisateur a cet objectif, arrive c'est-à-dire la motivation ou le bénéfice qu'il en pour savoir quand Raison tire. Dans ce cas, le client veut suivre ses mon colis arrive. commandes pour savoir quand son colis arrive.  13 Les User Stories Une user story se compose généralement de trois éléments principaux : le rôle, l'objectif, et la raison. Composant Description Exemple User Story Complète Il s'agit de la personne ou du groupe qui a besoin Rôle de la fonctionnalité. Le rôle permet de comprendre En tant que client, pour qui la fonctionnalité est développée. User Story 1 En tant que client, je je veux pouvoir L’objectif est l’action ou la tâche que l'utilisateur veux pouvoir suivre suivre mes Objectif souhaite accomplir. Ici, le client veut pouvoir suivre mes commandes en commandes en ses commandes en ligne. ligne pour savoir ligne quand mon colis Cela explique pourquoi l'utilisateur a cet objectif, arrive c'est-à-dire la motivation ou le bénéfice qu'il en pour savoir quand Raison tire. Dans ce cas, le client veut suivre ses mon colis arrive. commandes pour savoir quand son colis arrive.  13 Les User Stories Une user story se compose généralement de trois éléments principaux : le rôle, l'objectif, et la raison. Composant Description Exemple User Story Complète Il s'agit de la personne ou du groupe qui a besoin Rôle de la fonctionnalité. Le rôle permet de comprendre En tant que client, pour qui la fonctionnalité est développée. User Story 1 En tant que client, je veux pouvoir En tant que client, je L’objectif est l’action ou la tâche que l'utilisateur veux pouvoir suivre Objectif je veux pouvoir suivre mes commandes souhaite accomplir. Ici, le client veut pouvoir suivre en ligne suivre mes mes commandes en pour commandes en ses commandes en ligne.savoir quand mon colis arrive. ligne pour savoir ligne quand mon colis Cela explique pourquoi l'utilisateur a cet objectif, arrive c'est-à-dire la motivation ou le bénéfice qu'il en pour savoir quand Raison tire. Dans ce cas, le client veut suivre ses mon colis arrive. commandes pour savoir quand son colis arrive.  13 Les User Stories Les user stories sont délibérément simples et sont souvent écrites sur des cartes ou des notes adhésives lors des sessions de planification agile. En tant que client, je veux pouvoir suivre mes commandes en ligne pour savoir quand mon colis arrive.  13 Les User Stories Une fois la user story rédigée, elle ne se limite pas simplement à une déclaration écrite. Pour que l'équipe Agile puisse réellement comprendre et mettre en œuvre cette user story, il est crucial d'aller au-delà du texte. C'est là qu'intervient le concept des 3 C : Carte, Conversation, Confirmation. Ces 3 éléments permettent de transformer une simple description en une fonctionnalité bien comprise, discutée et validée. Ils assurent que la user story soit non seulement claire pour l'équipe, mais aussi correctement implémentée, en encourageant la communication continue et la validation des critères d'acceptation. En tant que client, je veux pouvoir suivre mes commandes en ligne pour savoir quand mon colis arrive. 13 Les User Stories La carte représente la user story de manière concise et claire. Elle contient juste assez d'informations pour identifier la fonctionnalité souhaitée et pour servir de point de départ aux En tant que client, je veux pouvoir suivre mes commandes en ligne discussions et à la planification. Au cours de la planification, pour savoir quand mon colis arrive. l'équipe peut ajouter des notes sur la carte concernant la priorité et le coût de la story. La carte est souvent remise aux développeurs lorsque la création de la story est programmée, Carte et rendue au client lorsque la story est terminée. 13 Les User Stories La conversation fait référence aux discussions approfondies entre les membres de l'équipe de développement, les parties En tant que client, je veux pouvoir suivre mes prenantes et les utilisateurs finaux. Ces conversations visent à commandes en ligne pour savoir quand mon colis arrive. clarifier et à détailler la user story, en explorant les attentes, les exigences et les implications plus larges de la fonctionnalité. Conversation 13 Les User Stories La confirmation consiste à définir les critères de réussite de la user story. Cela signifie spécifier les conditions ou les tests qui En tant que client, je veux pouvoir suivre mes commandes en ligne pour savoir quand mon doivent être satisfaits pour considérer la user story comme colis arrive. complète et conforme aux attentes. Les critères de réussite aident à valider que la fonctionnalité développée répond aux besoins et aux objectifs définis dans la user story. Confirmation 13 Les User Stories Une user story bien rédigée possède certaines caractéristiques qui sont résumées par l'acronyme I N V E S T Chaque lettre dans cet acronyme représente une caractéristique importante qui aide les équipes à rédiger des user stories de qualité, permettant une meilleure communication et une exécution efficace dans un cadre Agile. En tant que client, je veux pouvoir suivre mes commandes en ligne pour savoir quand mon colis arrive. IN VE S T Indépendante : Une user story doit être autonome et ne pas dépendre d'autres stories pour être réalisée. Cela permet de la planifier et de la développer sans créer de blocages dans l'équipe. L'indépendance facilite également la priorisation dans le backlog.  I NV E S T Négociable : Les user stories servent de supports aux discussions plutôt que de documentation exhaustive. Elles doivent être ouvertes à la discussion et à l'affinement en fonction des retours des parties prenantes et des membres de l'équipe.  IN VES T Valeur: Chaque user story doit apporter de la valeur à l'utilisateur ou au client. Il est essentiel de savoir pourquoi on développe cette fonctionnalité et quel impact elle aura sur l'expérience utilisateur ou les objectifs commerciaux.  I NV EST Estimable: Il doit être possible d'estimer l'effort nécessaire pour réaliser une user story. Si une user story est trop grande ou trop vague pour être estimée, cela signifie probablement qu'elle doit être décomposée en plus petites stories.  I NVE ST Small (Petite) : signifie que les user stories doivent être suffisamment petites pour être achevées en un seul sprint ou itération. L'objectif est de décomposer les fonctionnalités plus larges et plus complexes en éléments gérables qui peuvent être développés, testés et livrés dans le délai du sprint.  I NV ES T Testable: qui signifie que chaque user story doit inclure des critères d'acceptation clairs et mesurables qui permettent à l'équipe de vérifier si la fonctionnalité fonctionne comme prévu. Ces critères guident la création de tests de validation, apportent de la clarté, et réduit le risque de malentendus ou de défauts. Une histoire testable garantit également que la définition de terminé ou Fait est bien comprise par l'équipe et les parties prenantes.  14 Le Backlog Dans un projet Agile, une fois que les user stories sont rédigées, elles sont organisées dans un document clé appelé le backlog produit. Ce backlog est une liste unique et exhaustive de tout le travail à réaliser, comprenant à la fois les éléments fonctionnels (ce que le produit doit faire) et non fonctionnels (performances, sécurité, etc.). Chaque élément est priorisé pour s'assurer que l'équipe travaille toujours sur les aspects les plus importants, selon la valeur apportée aux utilisateurs ou aux besoins du business. L'un des grands avantages du backlog est qu'il sert de source unique d'information pour toute l'équipe, les parties prenantes, et le Product Owner. User Story User Priorité story N° En tant que client, je veux rechercher des produits afin que je puisse les acheter 4 1 En tant que client, je souhaite ajouter des produits à un panier afin de pouvoir les payer 2 2 En tant que CFO, je souhaite compléter une commande afin de pouvoir recevoir le paiement 3 3  15 Affiner le Backlog Affiner le backlog est une activité essentielle dans la gestion de projet agile qui consiste à examiner, prioriser et préparer les user stories ou les éléments du backlog pour les sprints à venir. Ce processus garantit que le backlog contient des éléments bien définis, de taille appropriée et priorisés, prêts pour le développement. Les principales étapes de l'affinage du backlog peuvent être présentées comme suit: o Revue des User Stories o Ajout de Nouveaux Éléments en fonction des besoins émergents, ou changements o Décomposition des User Stories o Estimation de l'effort nécessaire pour compléter chaque user story. o Des critères d'acceptation sont définis pour chaque user story  16 Estimation en story points Estimation en story points aussi appelé Dimensionnement relatif , est une technique utilisée dans la gestion de projet Agile pour estimer l'effort et la complexité des user stories ou des éléments du backlog par rapport les uns aux autres, plutôt que d'attribuer des valeurs numériques absolues telles que des heures ou des jours. Ici, l'équipe compare la taille ou l'effort d'une user story par rapport à une autre en se basant sur certains critères (par exemple, la complexité, le risque, l'effort requis). L'objectif est d'établir une échelle de tailles relatives où chaque user story se voit attribuer une valeur de story points qui représente sa taille relative par rapport aux autres stories.  16 Estimation en story points Voici un exemple concret d’estimation en Story Point en utilisant la suite de Fibonacci (1, 2, 3, 5, 8, 13). Supposons qu'une équipe Agile doit estimer 3 user stories basées sur leur complexité et leur effort : o User Story A: Créer un formulaire de contact simple sur le site web. L'équipe estime que cette tâche est relativement simple et nécessitera peu d'effort. Elle attribue donc 2 points à cette user story. o User Story B: Implémenter un système de paiement en ligne sur le site web. Cette user story est plus complexe que la première, car elle implique des intégrations avec des services de paiement et des considérations de sécurité. L'équipe estime que cela nécessitera un effort modéré. Elle attribue donc 5 points à cette user story. o User Story C : Développer une fonctionnalité de recommandations personnalisées basées sur l'historique des achats des utilisateurs. Cette user story est considérée comme assez complexe en raison de la nécessité de travailler avec des algorithmes de recommandation et des bases de données complexes. L'équipe estime que cela nécessitera un effort important. Elle attribue donc 8 points à cette user story.  16 Estimation en story points Dans cet exemple, les user stories sont estimées de manière relative par rapport les unes aux autres en utilisant des points de story. La user story C est considérée comme étant plus grande et complexe que la user story B, qui à son tour est plus grande que la user story A. Cette approche permet à l'équipe de comparer et de prioriser les user stories en fonction de leur taille et de leur complexité relatives, facilitant ainsi la planification et l'exécution des sprints. Exercice Question Vrai ou Faux Les estimations agiles sont exhaustives ; elles doivent inclure le temps nécessaire à la documentation et aux tests. Les estimations agiles sont en Timebox; une fois fixées, elles ne peuvent plus être modifiées. Les estimations agiles sont créées par le propriétaire du produit. Les équipes agiles créent leurs propres estimations. Le risque ne doit pas être pris en compte dans les estimations des user stories. Les équipes qui découvrent la méthode agile devraient faire appel à un chef de projet expérimenté pour créer les estimations à leur place. Exercice Question Vrai ou Faux Les estimations agiles sont exhaustives ; elles doivent inclure le temps nécessaire à la Vrai documentation et aux tests. Les estimations agiles sont en Timebox; une fois fixées, elles ne peuvent plus être Faux modifiées. Les estimations agiles sont créées par le propriétaire du produit. Faux Les équipes agiles créent leurs propres estimations. Vrai Le risque ne doit pas être pris en compte dans les estimations des user stories. Faux Les équipes qui découvrent la méthode agile devraient faire appel à un chef de projet Faux expérimenté pour créer les estimations à leur place. Le o Burndown Charte Suivi des o Burnup Charte Performances o Velocite  1 Les Burn Charts Les burn charts (ou graphiques de progression) sont des outils visuels utilisés en gestion de projet Agile, en particulier dans Scrum, pour suivre l’avancement du travail dans le temps. Ils permettent aux équipes et aux parties prenantes de comprendre combien de travail a été réalisé et combien il en reste. Il existe deux principaux types de burn charts :  1 Les Burn Charts Les burn charts (ou graphiques de progression) sont des outils visuels utilisés en gestion de projet Agile, en particulier dans Scrum, pour suivre l’avancement du travail dans le temps. Ils permettent aux équipes et autres parties prenantes de comprendre combien de travail a été réalisé et combien il en reste. Il existe deux principaux types de burn charts : Burn-Down Chart Burn-Up Chart Burn-Down Chart Un burn-down chart est une représentation visuelle utilisée en Agile pour suivre la quantité de travail restant dans un projet ou un sprint au fil du temps. Axe Y (Vertical) : Représente la quantité totale de travail, souvent mesurée en points d’histoire, tâches ou heures. Axe X (Horizontal) : Représente le temps, généralement divisé par jours dans le sprint. Burn-Down Chart Ce type de graphique affiche généralement 2 lignes : Progression réelle (Ligne bleue): Cette ligne représente la quantité réelle de travail restant dans le sprint, mise à jour régulièrement généralement quotidiennement. Elle montre combien de travail reste à faire. Au fur et à mesure que le sprint progresse, la ligne bleue devrait descendre, idéalement jusqu’à zéro à la fin du sprint, ce qui indique que tout le travail a été accompli. Burn-Down Chart Ce type de graphique affiche généralement 2 lignes : Progression idéale (Ligne verte): Cette ligne représente la progression idéale au fil du temps, suivant une trajectoire descendante droite, allant de la quantité totale de travail au début du sprint à zéro à la fin du sprint. La ligne verte sert de référence, indiquant le rythme prévu ou attendu pour l’achèvement du travail. Burn-Up Chart Le burn-up chart est utilisé pour suivre la quantité de travail accompli par rapport à la portée totale d’un projet ou d’un sprint. Ce type de graphique affiche généralement 3 lignes : Ligne de Portée : Représente la quantité totale de travail à effectuer (ligne bleue). Elle peut rester stable ou fluctuer pour refléter les changements de portée, comme l’ajout ou la suppression de tâches. Burn-Up Chart Le burn-up chart est utilisé pour suivre la quantité de travail accompli par rapport à la portée totale d’un projet ou d’un sprint. Ce type de graphique affiche généralement 3 lignes : Ligne de Travail Accompli (ligne blanche) : Montre l’avancement cumulatif du travail terminé. Cette ligne monte au fil du temps à mesure que les tâches sont complétées, idéalement en convergeant avec la ligne de portée lorsque tout le travail prévu est réalisé. Burn-Up Chart Le burn-up chart est utilisé pour suivre la quantité de travail accompli par rapport à la portée totale d’un projet ou d’un sprint. Ce type de graphique affiche généralement 3 lignes : Ligne de Progression Idéale (ligne verte) : Sert de référence pour une progression régulière. Les équipes peuvent comparer leurs progrès réels à cette ligne pour savoir si elles sont en avance, dans les temps ou en retard par rapport au planning.  2 La Velocite La vélocité est définie comme la mesure de la capacité de travail d’une équipe par itération. Cette mesure permet à l’équipe d’évaluer la quantité de travail qu’elle sera en mesure d’effectuer dans les itérations futures, en se basant sur la quantité de travail qu’elle a effectuée dans les itérations précédentes. Exo La vélocité de votre équipe a été de 40, 48, 52, 59 et 51 points par itération depuis le début du projet. Votre backlog contient 600 points de fonctionnalité restant. Votre sponsor veut savoir quand le projet devrait finir. Combien d’itérations supplémentaires seront nécessaires pour compléter le backlog?  2 La Vélocité 1. Vous devez d’abord calculer la moyenne de points par itération 40 + 48 + 52 + 59 + 51 / 5 = 50 2. Vous divisez ensuite le travail restant par la moyenne de points par itération 600 / 50 = 12 Par conséquent, le backlog nécessitera probablement 12 autres itérations. END