Bonjour
Je suis en train de lire le livre"scrum insights for practitioners" et je suis un peu surprise par le premier point de la liste des outcomes du daily ( voir photo)
Pour moi, L’objectif du sprint doit être fixe et on doit travailler pour l’atteindre pendant tout le sprint. La quantité de travail peut être ajustée mais pas l’objectif.
Qu’en pensez-vous de ce point ?
Merci
J’imagine que ça s’entend plus dans le sens de raffinage du but de Sprint mais sans le bouquin, c’est compliqué de dire.
Bonjour @Hanh_NGUYEN.
j’aurais envie de le comprendre dans le sens de la mise à jour vers l’avancement vers le sprint goal.
Comment l’escouade a pu avancer vers l’objectif du sprint.
Et en effet, à la sortie du Daily, nous devrions savoir comment nous avons pu avancer vers l’objectif de Sprint et comment cela va continuer 
Qu’en dis-tu?
En effet, le sprint goal est défini au début du sprint par l’équipe de développement en collaboration avec le Scrum Master et le Product Owner, et il est censé être clair et non modifié pendant toute la durée du sprint.
Cependant, il peut arriver que l’équipe rencontre des obstacles imprévus ou que les circonstances changent durant le sprint, ce qui peut rendre le sprint goal obsolète ou difficile à atteindre.
Dans ce cas, l’équipe peut choisir de mettre à jour le sprint goal pour mieux refléter les objectifs actuels du sprint et les défis auxquels elle est confrontée.
Cependant, il est important de noter que la mise à jour du sprint goal doit être un processus collaboratif et transparent impliquant tous les membres de l’équipe de développement ainsi que le Product Owner et le Scrum Master. (Et avec un Product Owner qui est dans sa réflexion, représentant des utilisateurs et parties prenantes)
De plus, la mise à jour du sprint goal ne doit pas être une décision prise à la légère et doit être justifiée par des raisons valables. Dans l’idéal, le sprint goal ne doit être modifié que rarement, de sorte que l’équipe puisse se concentrer sur la réalisation de ses objectifs sans interruption inutile.
Le texte dit bien « One Of These ».
Cela peut être vu comme un fusible. Un fusible, on espère qu’il ne va pas fondre. Et pourtant, c’est un cas à prévoir dans l’étude du circuit.
Il en va de même d’une interruption de sprint (qui est pour moi la version extrême de la mise à jour de l’objectif de sprint.
Si c’est pour répondre à un PSM ou une certif officielle, voilà ma réponse :
De mon expérience :
de nouveau il y a la notion de « frequence », de « motivation » de ce choix de le changer.
Ne pas se l’interdire si ca peut débloquer une situation, bien entendu.
Mais si ca devient une habitude ou une carte magique à la 49.3 à chaque envie, alors autant arrêter d’utiliser le sprint goal (et de dire qu’on fait du scrum)
Merci pour vos différents retours
Il s’agit d’un passage de ce livre, recommandé à lire sur le site Scrum. Org et que j’ai trouvé une version téléchargeable ici
Je suis complètement alignée avec le point de vue de @BenjaminF sur le sujet. Pour moi le sprint backlog est à mettre à jour tout le long du sprint en fonction de son évolution et à chaque daily on regarde s’il y a des obstacles à relever ou contourner mais l’objectif du sprint doit être fixe. Au cas où ça devient obsolète, on annule le sprint, mais cela doit être exceptionnel, en aucun cas, on le modifie au fur et à mesure à chaque daily
Hello, je suis complétement aligné avec ce qui a été dit par rapport a l’état de l’art mais je vois aussi que ce document date de 2016 (après septembre d’ailleurs). Que disait le scrum guide en 2016 (version 2013 je pense du coup ?) pour comparer ?
Je viens de remettre la main dessus et meme chose en 2013
« No change are made that would endanger the Sprint Goal »
Son objectif (Sprint Planning) est de décider des éléments du Carnet de produit à développer dans la limite du temps imparti. Elle prévoit également la façon de s’organiser pour y parvenir.
dixit : Scrum Scrum Guide via Scrum-League
Le Sprint Goal définit il la durée du Sprint (1 à 4semaines) ?
Pour autant que je sache, la durée de sprint est decidé par l’équipe :
Ensuite l’équipe s’y tient et peut la revoir de temps a autre en retro pour ajuster
Mais l’idée est que cela devienne une cadence fixe et que l’on apprenne a etre plus efficace dans cette boite de temps fixée en experimentant et reposant sur l’empirisme.
Lorsque l’équipe co-construit le sprint backlog, elle connait la durée du sprint et donc c’est plutôt la durée qui influence le sprint goal que l’inverse (on ne va pas se donner un objectif que l’on ne peut pas tenir dans le délai imparti)
Merci Benjamin pour ta réponse, entre autres :>
Lorsque l’équipe co-construit le sprint backlog, elle connait la durée du sprint et donc c’est plutôt la durée qui influence le sprint goal que l’inverse (on ne va pas se donner un objectif que l’on ne peut pas tenir dans le délai imparti)
En effet le sprint Goal tenant compte des items sélectionnés, il est favorable que la durée soit adaptée pour pouvoir les voir potentiellement livrables.
Pour être honnête, par théorie j’ai toujours pensé que time=xsem DONC on opte de se pencher sur tels items.
C’est hors sujet mais Stricto sensu, c’est l’inverse.
Les pbi sont sélectionnés tenant compte de l’objectif de sprint.
Désolé, à 110%, je m’en veux.
En effet, ce que j’avais en tête : « les items alors sélectionnés dans le but de répondre à l’objectif du Sprint. »
Au temps pour moi, cette erreur ne se reproduira plus.
Merci Scrum Life pour les sujets partagés qui développent toujours plus mon appétence pour votre métier.
Je suis obligé de rebondir là-dessus :
Attention grosse mise en garde, concrètement ils disent beaucoup beaucoup de bêtises chez Scrum League, je ne te conseille vraiment pas d’utiliser cela comme document de référence.
D’un côté ils présentent une version assez datée de Scrum (je t’invite à aller sur https://scrumguides.org/ pour consulter la version 2020 – il existe une traduction française disponible sur le même site), de l’autre ils ont des choix de vocabulaire et de conseils assez malheureux qui reflètent une utilisation de Scrum très orientée vers « renommons les choses mais ne changeons rien sur le fond ».
En particulier, pas d’approche produit. On met dans le backlog produit « la liste des exigences » (je reprends les mots du site), on n’envisage pas d’alternative à estimer les éléments du backlog, etc. (je ne vais pas rentrer dans le détail, a minima je t’invite à lire le Scrum Guide 2020 et/ou regarder la playlist de Scrum Life qui décortique tout Scrum, nous l’avons également inclue dans notre formation gratuite)
Jean Pierre,
Merci pour votre mise en garde et mea culpa pour les quelques erreurs que j’ai pu glisser dans le forum.
A savoir que je m’intéresse énormément aux différents sujets abordés par les différents membres Scrums Life et entraider, et âr conséquent, au delà de ne pas connaître, je n’ai pas les bonnes bases.
Pour finir pour ce post, j’ai reçu la certification Scrum league, celà veut alors dire qu’elle n’est pas conforme ?
Maintenant pour faire simple si je suis intéressé par Scrum et qui plus est par la chaîne SCRUM LIFE.tv c’est qu’elle convient à mon état d’esprit orienté pratique et amélioration par l’approche empirique dont j’avais pris connaissance avant 2020.
Salut Johann,
Pour être très clair, les seules certif « officielles » sont celles de scrum.org et de scrumalliance, puisque ce sont les certifs des créateurs de Scrum.
Ensuite, il y a la notion de reconnaissance pour toutes les autres certifs. C’est à dire « ce qu’en pensent les gens » et dans ce groupe, il y a « ce qu’en pensent les experts du métier ».
Dans cette dernière (et on en fait parti chez Scrum Life), effectivement Scrum League a une mauvaise réputation.
Qu’est-ce que ça veut dire ? Que malheuresement, pour les gens qui s’intéressent à l’agilité et se documentent dessus, ta certification scrum league risque de leur (nous) dire : « ok s’il la met en avant et ne connait que ça, il ne connaît pas Scrum ».
Ca ne t’empêche pas d’être un bon Scrum Master, mais la certif que tu mets en avant peu induire l’inverse dans la tête des autres.
Maintenant, si tu te reconnais dans le message et l’état d’esprit de Scrum Life, tu peux encore être sauvé
Mon conseil : ne prend pas pour argent comptant ce que tu as pu apprendre ou valider via Scrum League. Ils n’ont clairement pas compris Scrum comme nous. Ni comme les créateurs de Scrum d’ailleurs ^^
Donc profite de la commu, du forum, n’hésite pas à poser des questions et à réagir.
