La DoD aide à déterminer si un item du backlog de sprint (US par exemple) peut être considéré comme terminé.
Elle fluidifie le travail des développeurs (codeur)
Aligne l’équipe technique et métier sur le résultat attendu en fin de sprint.
Évite les allez retours et les déceptions
Elle est garante de la qualité du produit
Un accord sur la notion de terminé
…
Une fois que l’élément de backlog répond à ces critères, il peut être déployé.
Que dit le guide SCRUM
La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait les mesures de qualité requises pour le produit.
Dès qu’un élément du Product Backlog satisfait à la Definition of Done, il se transforme en Increment. La Definition of Done apporte de la transparence en permettant à chacun une compréhension commune du travail Fini dans le cadre de l’Increment. Si un élément du Product Backlog n’est pas conforme à la Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alors renvoyé au Product Backlog pour être pris en compte ultérieurement.
Les critères d’acceptations du ticket sont tous validés
Les différents test ont été réalisés et le résultat accepté par les différents acteurs de la qualité du produit (PO, Codeur, Testeur, …)
La doc nécessaire a été mise à jour
Les maquettes graphiques sont respectées
Livré dans un environnement stable (possible en DevOps)
Il est tout a fait envisageable que selon le contexte (frontend, API, …) des parties de la DoD ne s’appliquent pas à certains ticket. (Storyotype)
Attention tout de même …
La definition of done ne doit pas être une liste infinie de critères impossible à terminé durant le sprint. Elle est un engagement fondamental de l’équipe a fournir un ticket finit et ne dois pas devenir une contrainte (dans le sens difficilement réalisable)
La définition doit rester simple pour être comprise par l’ensemble de l’équipe du projet. Il n’est pas non plus utile de chercher la sur-qualité et de mettre les objectifs de sprint en difficulté. Il est inutile de commencer par une définition super élaborée, nous l’affinerons avec le temps.
Elle évolue
Comme mentionné auparavant, on amendera la définition, donc à un moment, des items réputé « done » ne correspondront pas à cette définition.
Le mot de la fin
La DoD aide à augmenter la qualité d’un ticket
Elle est le fruit d’une discussion ouverte entre tout les membres de l’équipe.
Elle n’est pas figée dans le temps et donc évolue en fonction de la maturité de l’équipe
Ses principaux avantages sont l’optimisation de la rédaction, de l’estimation, le gain de temps lors du sprint planning
Attention, la DoD ne doit pas être un frein, elle ne doit pas être une liste à rallonge de critères qui sont peu ou pas utiles à l’équipe, elle doit être réalisable, ajustable et adaptée à l’équipe du projet.
C’est probablement une excellente démarche que d’entreprendre des estimations, cependant, il y a quelques pièges à éviter. Voici une courte liste de points d’attention
Savoir ce qu’est une estimation
Je te conseille la lecture de cet excellent article sur ce que sont les estimations . (Il est excellent car c’est moi qui l’ai rédigé ;))
Avoir un ticket de référence
La dérive des continents estimations. Sans baseline, ou référence comparative, les estimations vont se décaler, de ce fait, la vélocité, le burndown chart et autres indicateurs ne seront plus fiables.
Ne pas convertir les estimations en jour-homme
Les jour-homme créent une complexité inutile et annulent complètement l’intérêt d’estimations relatives qui permettent à tout le monde travaillant à des vitesses différentes de se comprendre et de se mettre d’accord.
Ne pas estimer uniquement en fonction de la complexité
Si on estime uniquement la complexité, une story « simple » mais demandant beaucoup d’effort. (Par exemple une tâche à répéter un certain nombre de fois, des tests longs …). Cela va créer de fausses prédictions et un manque de visibilité sur la quantité / charge de travail à réaliser dans le backlog.
Voici un tableau comparatif « à la suédoise » de la notion de complexité par rapport à la notion d’effort.
Ticket
Remarque
Comp.
Effort
En tant que constructeur, je souhaite monter un tabouret MARIUS afin de poser mes fesses
3 visses à serrer
1
1
En tant que constructeur, je souhaite monter un tabouret SKOGSTA afin de poser mes fesses
Un rien plus complexe que le MARIUS
2
2
En tant que constructeur, je souhaite monter un lit NORDLI afin de pouvoir dormir
C’est bien plus compliqué qu’un tabouret et les tiroirs sont super dur à mettre en place
5
5
En tant que constructeur, je souhaite monter 10 tabourets SKOGSTA afin de poser mes fesses et celles de mes invités
Aussi complexe simple qu’un SKOGSTA . (Nous aurions également pu considérer l’expérience)
2
20
Exemple de la complexité VS l’effort pour la réalisation d’un ticket
Ne pas considérer une estimation comme quelque chose de précis, gravé dans le marbre
Jamais l’équipe et/ou les parties prenantes ne peuvent considérer une estimation comme un contrat. L’estimation est surtout valable au moment où elle a été faite, la solution évoluant au jour le jour, il est envisageable qu’un item soit impacté par la réalisation d’un autre qui n’existait pas au moment de l’estimation. (Si il existait déjà, il faut absolument lier les 2 tickets et marquer le dépendance). Il n’y a pas que l’application qui évolue, les développeurs aussi, dans la plus part des cas, il considérera le ticket comme plus « simple » et tout le monde y gagnera.
Ne pas considérer les estimations comme une mesure de productivité des équipes, ou pire, des développeurs.
Dans ce cas, nous verrons très vite apparaitre des dérives telles que surestimation systématique, sous engagement dans le sprint pour être sûr de le terminer.
Certains développeurs feront des heures supplémentaires et seront donc moins alertes et moins qualitatifs. D’autres simplement bâcleront le travail pour tenir le délai, ce qui générera inévitablement de la dette technique
Les estimations ne sont en aucun cas à utiliser pour contrôler l’équipe et/ou un développeur en particulier
PiPo
Ne pas comparer les estimations de deux équipes
Il est tentant de comparer les performances des équipes en convertissant l’estimation en chiffre et en divisant le total d’un sprint par le nombre de jours de ce dernier (et de faire un prorata par développeur). Hé bien, ça ne fonctionne pas, car une estimation pour l’équipe A n’est pas une estimation pour l’équipe B.
Faire attention aux changement dans l’équipe
Si une personne sort de lʼéquipe, cette dernière aura moins de force de travail, donc, la vélocité va décroitre.
Si une personne rejoint lʼéquipe, dans un premier temps, la vélocité va également décroitre (Lʼonboarding va occuper dʼautres membres de lʼéquipe, la nouvelle personne ne sera pas efficiente à 100% au début …) Sur le long terme, la vélocité devrait croitre et dépasser la vélocité initiale. Si ce n’est pas le cas, il faut absolument comprendre pourquoi.
Ne pas forcer à estimer
Jamais les développeurs ne doivent se forcer / être forcé à estimer un ticket. Si un ticket ne peut être compris, il ne doit pas être estimé. Une fois que l’estimation existe, elle est utilisée par les autres membres de l’équipe, or, si elle n’est pas correcte, elle faussera les travaux de ses utilisateurs.
Ne pas estimer avec une seule personne
Durant une session d’estimation, avec plusieurs participants, nous arrivons de temps à autre à des résultats différents, ce qui permet d’ouvrir un débat et amène généralement des questions sur le travail à effectuer. Nous y gagnions en précisions.
En dehors de cela, avoir une équipe avec un seul développeur n’est pas prudent, imagine l’impact si ce dernier quitte le projet …
L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.
C’est pour les équipes qui utilisent les estimations probablement la dernière étape pour passer le ticket en ready (DoR)
Pourquoi estimons-nous?
Réduire au maximum les risques
La session d’estimation sert à mettre au jour et diminuer les zones d’ombre et risques du projet. Une fois ces dernières connues, on peut choisir comment les traiter:
Un Spike. Il est utilisé quand on ne connait pas encore la solution technique qui peut être apportée à un problème (idéalement, on fera un ou plusieurs POC).
Inclure cette inconnue dans l’estimation.
Servir de support à la prise de décision et à la priorisation
Avant de développer une fonctionnalité, il est intéressant d’avoir une idée de son coût. Une entreprise qui investit doit pouvoir estimer son ROI (retour sur investissement), cette information servira également dans la priorisation du backlog, c’est la raison pour laquelle il est possible qu’une story estimée ne soit jamais développée. Quand une application doit être mise en production, en fonction du nombre de sprint disponible et du « coût » de développement, on priorisera différemment certaines features. Faut-il engager plus de développeurs, testeurs, analystes et techniques pour augmenter la valeur livrée?
Établir la confiance
Pour que la confiance règne entre les parties prenantes d’un projet (clients, décisionnaires, PO), il faut que l’équipe soit fiable sur sa capacité à livrer ce qui est promis. Les estimations nous guident dans ce que nous devrions être capables de livrer dans un futur plus ou moins proche. Grâce à cette donnée objective, nous pourrons plus facilement négocier le périmètre des releases
Aligner lʼéquipe et partager lʼinformation
Les estimations permettent de sʼassurer dʼune compréhension commune du périmètre, de la valeur à produire et de se mettre dʼaccord sur la « taille » dʼune fonctionnalité.
Pour découper les User Stories (US)
Quand nous lisons, comprenons et estimons un ticket, nous pouvons parfois nous apercevoir que cette dernière est trop importante. Dans ce cas, nous le divisons en ticket plus petit. Nous augmentons la granularité du backlog et renforçons la prédictibilité du travail.
Pour organiser le sprint backlog produit du point de vue de la valeur, de l’effort.
Si nous connaissons lʼeffort nécessaire à la réalisation dʼun ticket, nous pouvons déterminer si ce dernier est réalisable dans le sprint.
Planification
Cʼest également un bon moyen pour estimer le nombre de sprint nécessaire à la réalisation des tickets souhaités dans une release via un forecast. On peut également communiquer plus facilement les causes d’un changement de plan, par exemple, si l’on découvre que l’intégration d’un système à notre application est plus complexe que prévu, on peut aisément démontrer l’effet sur ce que nous avions prévu.
/!\ Le forecast n’est absolument pas un outil permettant de prévoir avec certitude quand une application serra développée.
Le Jardinier
Que représente une estimation?
Nous allons ici explorer plusieurs hypothèses sur le que/quoi et le comment estimer, selon quelle métrique.
Des jours hommes / du temps?
L’humain est incapable d’estimer correctement son temps
Une date ne prend pas en compte les facteurs externes tels que les emails, les meeting, les conversations informelles, lʼaide apportée par un développeur à un autre … (Habituellement, nous considérons quʼun développeur développe environ 6h/ jour)
Le temps / les dates ont une valeur émotionnelle qui finira par oppresser les développeurs et le poussera soit à diminuer la qualité de son travail pour gagner du temps, soit à augmenter le temps prévu.
Le temps nécessaire pour un développeur ne sera pas le même que pour un autre.
Pour illustrer mon propos
Prenons le cas d’une course à pied selon le point de vue d’un analyste ayant fait un Iron Man et d’un Scrum Master de 110 kg.
Si on demande une estimation en temps pour les 20km de Bruxelles, le premier répondra 2h30, le second 6h (sans certitude de terminer). Ajoutons à cela que c’est une tierce personne qui va courir le jour J, il est totalement impossible de prédire le temps qui sera nécessaire. (Même un calcul savant donnerait une réponse erronée). En revanche, si on demande d’estimer l’effort, la réponse sera pour les deux 20km. Et si demain on parle d’un marathon, on sait que l’effort est peu ou prou le double.
Pour les tickets, c’est la même chose, si on estime en jours/homme, on doit savoir qui fera la tâche.
De la complexité?
Au plus c’est complexe à réaliser, au plus la valeur de l’estimation serait élevée, et inversement. C’est en effet un point de départ intéressant, mais qui a ses limites.
Pour illustrer mon propos
Considérons une équipe de deux personnes composée d’un enfant et d’un chirurgien du pied. Considérons 2 tickets (Nous supposons que les activités prennent le même temps.), construire 1000 personnages Lego et réaliser une reconstitution du pied (le pauvre a marché sur une brique).
Si nous parlons complexité, l’opération du pied aura une estimation bien plus élevée que le montage des personnages. Si le but était de planifier et de savoir quand l’équipe aurait terminé, puisque le temps de réalisation est plus ou moins identique, l’estimation aurait dû être la même. En fait, on peut dire que si la complexité des tâches varie, l’effort à fournir est comparable.
Un risque
Dans cette hypothèse, nous considérons qu’au plus le travail est risqué, au plus l’estimation devrait être élevée, et inversement. C’est assez risqué de prendre uniquement cette donnée pour une estimation.
Pour illustrer mon propos
Considérons l’estimation de la durée du voyage maison boulot en transport en commun et en trottinette. Le transport en commun est plus rapide, mais « risqué » (Présence de bouchon, des gens dans les voies (oui, la SNCB dit bien dans les voies). La trottinette, même électrique, c’est plus « sûr », mais c’est lent (oui bon, on ne va pas prendre en considération le nombre de personnes aux urgences après une chute). Une estimation en risque serait plus élevée pour le transport en commun, cependant, il est tout à fait possible que vous arriviez plus vite en bus qu’en trottinette au boulot demain. (Si demain est un weekend, ne vient pas au bureau).
Mais alors quoi?
Et bien, nous devrions surtout parler d’une notion d’effort qui reprendrait toutes les hypothèses précitées. La quantité de travail à fournir, sa complexité, ses risques et inconnues, le temps.
Quelle mesure pouvons-nous utiliser pour représenter l’effort?
T-shirt sizing
À mon sens, à utiliser pour du haut niveau, par exemple pour se donner une idée avant analyse
Valeurs disponibles: XS, S, M, L, XL …
Les animaux
De nouveau, nous sommes sur quelque chose destiné à du haut niveau. Avant l’analyse, Épic …
Valeurs possibles: Puce, tigre, éléphant …
Les StoryPoints
À utiliser pour des tickets pour lesquelles nous avons beaucoup d’informations, voir, plus d’inconnue.
Valeurs disponibles: 1, 2, 3, 5, 8, 13 …
D’autres articles suivront sur ces différentes mesures.
Quand on estime un ticket, ce n’est pas je qui estime, mais nous. Toutes les estimations sont le résultat d’un travail d’équipe.
Le Jardinier
Pourquoi parler de relativité (E=mc²)?
Reprenons notre exemple de course, si notre première estimation était faite pour une course de 20 km, nous pouvons aisément estimer que l’effort nécessaire à 10km sera de 1/2 tandis que l’effort pour 40km sera le double. De la même manière, les autres mesures permettent à l’équipe un accord sur la taille relative des tickets. Par exemple, la story 2 représente 1/2 des efforts de la 1. La story 3 représente 2 fois la somme d’effort de la première.
Estimer de manière relative prend en compte l’imprécision de nos estimations. En effet, les humains ne sont absolument pas doués pour ce genre de chose, par contre, ils sont tout à fait capables de comparer 2 choses entre elles.
Revenons à nos Lego, en voyant un tas, vous ne seriez pas en mesure de donner le nombre de briques qui le compose, par contre, vous pouvez comparer 2 tas et dire qu’il y en a plus dans celui-ci. Vous pourriez également dire qu’ils sont à peu près identiques …
On peut faire le même exercice avec des verres d’eau (ou de Vodka).
Le premier verre est la référence
Nous pouvons estimer que le second est plus rempli
Le troisième est aussi rempli que le 1er (à moitié vide, ou moitié plein …)
It’s difficult to make prediction, especially about the future
Variation du résultat par rapport au travail à fournir
Nous devons garder à lʼesprit que même si lʼéquipe est normalement capable de développer entièrement le produit, nous travaillons avec des spécialistes. Donc, si durant une période donnée, il y a moins de travail dans un domaine, la quantité de travail fournie par l’équipe va mécaniquement diminuer.
Précisions
Il est impossible d’obtenir un chiffre précis quoi que nous fassions. Par contre, au fil du temps, pour une équipe stable, la corrélation estimation de l’effort et nombre de tickets done dans un sprint sera de plus en plus exacte, et donc, la prédiction moyen terme également.
Last but not least, les estimations, ce n’est pas SCRUM, c’est XP.
Ils déclenchent le processus de réflexion de l’équipe et amènent à penser, à comment une fonctionnalité va se comporter du point de vue de l’utilisateur final (persona)
Souviens toi, une story c’est surtout une amorce à la discussion / réflexion.
Servent de base aux cas de test
Aide l’équipe à écrire des cas de tests précis et sur base des critères accepté par tout le monde et donc cohérent sur l’ensemble de la vie du ticket.
Ils décrivent également des scénarii négatifs , et des unhappy flow
Ils affinent le scope
Définissent la portée, les limites du ticket et réduisent les ambiguïtés. Ils clarifient.
Garantie
Ils garantissent que tous les parties prenantes et utilisateurs ont une compréhension commune et sont satisfaits de ce qu’ils obtiennent.
Ils aident à l’estimation
Ils présentent ce qui doit être exactement développé par l’équipe. Grâce à ces exigences précises, l’équipe peut éventuellement diviser en tâches qui aideront à une estimation globale. (Du coup, ça aide aussi à diviser une story en « sous-story »)
Les critères d’acceptation sont indispensables, car ils évitent les résultats inattendus et mettent tout le monde d’accord sur la manière dont va être implémenté un ticket.
Le Jardinier
Qui rédige les critères d’acceptation?
Le PO bien entendu …
Tout le monde le sait, le PO, il fait beaucoup beaucoup de chose, donc, il délègue. Il délègue a qui veut / peut le faire dans l’équipe.
Les analystes qui connaissent bien le sujet du ticket
Le métier qui en faisant cela s’assurera que le besoin exprimé sera bien rempli
Le développeur qui confirmera sa compréhension du ticket
Le QA qui va chercher la petite bête, l’incohérence dans le récit
La manière la plus efficace de créer les critères d’acceptation est très certainement un savant mélange des différents rôles et compétences.
Le Jardinier
Quand rédiger les critères d’acceptation?
Avant le développement du ticket. (Merci capitaine Obvius)
Durant les exercices d’affinage du backlog
Durant l’analyse d’une demande métier
A la rédaction de la demande métier
Durant une phase de discovery
Le format
La check liste
Critère 1
Critère 2
Critère n
Le(s) scénaro(ii)
Étant donné …
Lorsque …
Alors …
Pour les critères de scénario, gherkin, c’est pas mal du tout
Autre
Libre à toi de créer un format qui correspond à ton équipe.
N’hésite pas à le proposer en commentaire
Quelques exemples
Consulter la fiche d’un livre sur un site d’e-commerce
En tant que client du site, je souhaite chercher un livre en spécifiant ou son auteur, ou son titre, ou son ISBN afin de consulter sa fiche
La description du contenu à afficher pour la fiche descriptive du livre de même que la mise en page de la liste de résultat sont décrites dans d’autres tickets.
Liste
Résultat unique: je peux directement consulter la fiche descriptive du livre
Pas de résultat: je suis invité à effectuer une nouvelle recherche
Plusieurs résultats: Je suis invité à choisir parmi une liste de livres
Scénario
Un seul résultat
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a qu’un résultat Alors je consulte directement la fiche descriptive du livre
Pas de résultat
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a pas de résultat Alors je suis invité à effectuer une nouvelle recherche
Plusieurs résultats
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il y a plusieurs résultats Alors je vois une liste de résultat et peux choisir celui qui m’intéresse
Il est préférable d’utiliser le « je » dans les critères d’acceptation, cela aide à se mettre dans la peau de l’utilisateur, à garder son point de vue et ses besoins à l’esprit
Le Jardinier
Connexion d’un utilisateur non connecté possédant déjà un compte utilisateur
En tant qu‘utilisateur non connecté, je souhaite introduire mon nom d’utilisateur afin d’avoir accès à mon profile
Liste
Nom d’utilisateur et password correcte: affichage du profile utilisateur
Nom d’utilisateur et / ou password erroné: affichage d’un message d’erreur
Nom d’utilisateur et / ou password erroné pour la troisième fois: affichage blocage compte
Scénario
Nom d’utilisateur et password correcte
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis mon nom d’utilisateur et mon mot de pass (correcte) et que je clique sur le bouton de connexion Alors je suis connecté au site.
Num d’utilisateur ou password incorrecte
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte ».
Num d’utilisateur ou password incorrecte troisième fois
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion pour la troisième fois dans un temps de 300 secondes Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte, votre compte est maintenant bloqué ».
Ajouter un livre dans le panier
En tant qu‘utilisateur connecté, je souhaite ajouter un livre dans mon panier afin de l’acheter
Liste
Le livre peut être livré dans mon pays: le bouton « Ajouter au panier » est disponible
Le livre ne peut être livré dans mon pays: le bouton n’est pas affiché, à la place se trouve un message stipulant que le livre ne peut être livré dans mon pays
Scénario
Je suis dans une zone géographique permettant la vente
Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre Lorsque je suis sur la fiche du livre Alors le bouton « Ajouter au panier » est visible.
Je suis dans une zone géographique ne permettant pas la vente
Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre Lorsque je suis sur la fiche du livre Alors le bouton « Ajouter au panier » n’est pas visible, à la place, un message m’informe que le livre ne peut pas être livré à ma localisation.
Alors oui, je sais, ce n’est pas le meilleur exemple, on pourrait toujours ajouter le livre sans être connecté …
Oups, nous n’avons pas terminé tout ce que nous avons promis …
Pourquoi est-ce qu’il reste un / des tickets dans le sprint
La première étape est de déterminer pourquoi nous n’avons pas terminé le sprint. Nous devrons également répondre à la question suivante: « Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction ».
Une question de capacité
Dans le cas d’un début de projet, il est probable que nous n’ayons pas encore trouvé notre vitesse de croisière, nous remplissons donc le sprint en tâtonnant jusqu’à savoir ce que nous sommes capables de réaliser au cours de la timebox.
Un changement dans l’équipe entraine une perturbation (dans la force). Une personne en moins diminue d’office la capacité de réalisation de l’équipe, logique me diras tu, cependant, une nouvelle recrue va également diminuer la vélocité (dans un premier temps) Quand un nouveau rejoint le projet, il va devoir prendre connaissance du métier, de la problématique que l’équipe résout par son travail, il va également apprendre le fonctionnement de l’équipe, et pour ce faire, les autres membres de l’équipe vont perdre investir du temps pour le former. Donc, en plus de ne pas bénéficier tout de suite d’une augmentation de vélocité, nous allons également en perdre.
Attention, la perte de vélocité doit être à court voire moyen terme, si cette perte perdure, il faut envisager que la nouvelle recrue a été mal intégrée, qu’elle ne correspond pas au projet ou encore que l’équipe devient trop importante et ne se synchronise plus correctement. Dans tous les cas, il faut agir.
Une mauvaise estimation
Et oui, une estimation reste une science inexacte, de temps à autre, nous nous trompons. Nous surestimons ou sous-estimons. La plupart du temps, nous arrivons à l’équilibre.
Une erreur de compréhension
Nous sommes humains, nous avons plein de possibilités de ne pas nous comprendre, alors, oui, il arrive que nous comprenions une chose alors que ce n’était pas du tout ça.
À la revue par les pairs, nous nous rendons compte que ce n’est pas du tout ce qui était demandé.
Ah zut, je n’avais pas ben compris, et je n’ai pas anticipé ces changements, c’est plus compliqué, ça prend plus de temps …
Ah, en fait, maintenant que j’ai compris, je vois que nous avons une dépendance vis-à-vis d’une autre équipe, d’un autre fournisseur …
Ah, l’équipe a changé entre le moment ou ce ticket est passé à prêt et le développement (Oui oui, ça arrive)
Que faire avec les tickets que nous n’avons pas terminés durant notre sprint?
Il n’y a pas de réponse simple, c’est au cas par cas.
La logique voudrait que s’il y avait un ticket X dans le sprint venant de se terminer, c’est qu’il faut le réaliser, donc, hop sprint suivant. Cependant …
La fonctionnalité à développer arrive trop tard, et n’a donc plus de raison d’être.
Le produit a pivoté, la fonctionnalité n’est donc plus aussi prioritaire, voir, plus nécessaire.
D’autres items ayant une priorité plus élevée sont apparus dans le backlog
L’item ne peut pas être réalisé, car il y a des dépendances non résolues
Pour ma part, je considère que si un ticket a été commencé, il est préférable de le terminer. En effet, si nous laissons les changements tels quels, suite aux autres évolutions, le travail sera probablement entièrement à refaire pour être intégré dans la solution qui aura évolué. (Tout en prenant en compte les points précédemment cités)
Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction
Heu, ben oui, en fait, il sert à quoi le daily, si ce n’est justement faire un topo sur la santé du sprint, inspecter au jour le jour que nous pouvons respecter le sprint goal et réaliser tout le contenu initialement prévu.po Si nécessaire, nous nous devons de réaménager le contenu du sprint en accord avec les dev et le PO tout en respectant le sprint goal.
Tout ça pour dire que ça ne devrait pas arriver car nous devrions avoir géré le problème en amont.
Pour offrir les meilleures expériences, nous utilisons des technologies telles que les cookies pour stocker et/ou accéder aux informations des appareils. Le fait de consentir à ces technologies nous permettra de traiter des données telles que le comportement de navigation ou les ID uniques sur ce site. Le fait de ne pas consentir ou de retirer son consentement peut avoir un effet négatif sur certaines caractéristiques et fonctions.
Fonctionnel
Toujours activé
Le stockage ou l’accès technique est strictement nécessaire dans la finalité d’intérêt légitime de permettre l’utilisation d’un service spécifique explicitement demandé par l’abonné ou l’internaute, ou dans le seul but d’effectuer la transmission d’une communication sur un réseau de communications électroniques.
Préférences
Le stockage ou l’accès technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou la personne utilisant le service.
Statistiques
Le stockage ou l’accès technique qui est utilisé exclusivement à des fins statistiques.Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
Marketing
Le stockage ou l’accès technique est nécessaire pour créer des profils d’internautes afin d’envoyer des publicités, ou pour suivre l’internaute sur un site web ou sur plusieurs sites web ayant des finalités marketing similaires.
