[Laurent]

Bonjour julie, je vois qu’arnaud à repondu à votre demande, si besoin n’hesitez pas à me le dire.

Excellente journée

• Cette réponse a été modifiée le il y a 2 mois par Laurent.

[Laurent]

De rien désolé du retard de réponse j’étais complètement passé à coté de votre question 😅

[Laurent]

Bonjour,

Pour mieux comprendre ces questions et leurs réponses, je vais vous donner quelques éclaircissements.

Question 1 : L’équipe Scrum est en effet en discussion constante avec le Product Owner (PO) concernant les priorités du backlog produit. Cependant, c’est bien le PO qui a le dernier mot sur ce sujet, car il est responsable de maximiser la valeur du produit et du travail de l’équipe de développement.

La réponse “2- Les contester auprès des parties prenantes” est correcte dans le sens où l’équipe Scrum, en désaccord avec le PO, peut partager ses préoccupations avec les parties prenantes. Cependant, cela ne signifie pas que l’équipe Scrum peut outrepasser le PO et revoir les priorités de manière autonome.

Question 2 : Les objectifs de qualité dans le contexte Scrum correspondent effectivement à la Definition of Done (DoD), mais ils concernent également d’autres aspects qualitatifs du produit. Par exemple, ils pourraient concerner des standards de code, des tests d’acceptation, ou encore la performance du produit.

La réponse “1- il faut maintenir les objectifs de qualité même si l’équipe n’avance pas comme prévu” est correcte car le respect de ces objectifs de qualité est essentiel pour garantir un produit viable et de haute qualité.

La réponse “3- On peut rediscuter Les objectifs de qualité” est également correcte car, dans un contexte Scrum, l’amélioration continue est clé, et cela inclut une réévaluation régulière des objectifs de qualité. Cela se fait généralement lors de la rétrospective, comme vous l’avez bien mentionné, ou à d’autres moments appropriés.

Cependant, il est important de noter que rediscuter des objectifs de qualité ne signifie pas nécessairement les abaisser pour accélérer le développement. Il s’agit plutôt d’identifier des moyens d’améliorer la qualité ou de rendre le processus de développement plus efficace.

[Laurent]

Bonjour,

Concernant le grooming des user stories lors de l’itération planning, même si vous avez plusieurs itérations prêtes d’avance, il est toujours recommandé de consacrer du temps au grooming des user stories pour les itérations à venir. Cela permet de s’assurer que les user stories sont claires, bien comprises et estimées de manière appropriée. Même si les grandes lignes du backlog sont déjà définies, des ajustements et des détails peuvent être nécessaires pour chaque itération spécifique.

Pour ce qui est de la business value des objectifs non attribués (uncommitted objectives), elle n’est normalement pas prise en compte dans le calcul de l’actual business value (BV). L’actual BV est généralement basée sur les user stories qui ont été effectivement terminées et validées lors de l’itération. Cependant, les uncommitted objectives peuvent être pris en compte pour le calcul de l’achievement, qui mesure le pourcentage d’accomplissement des objectifs fixés pour l’itération.

Concernant la rétrospective du PI planning, les sujets abordés peuvent varier en fonction des besoins et des objectifs spécifiques de l’équipe ou de l’ART (Agile Release Train). Cependant, certains sujets courants peuvent inclure l’évaluation des points forts et des points faibles du PI planning lui-même, l’identification des améliorations à apporter pour les futurs PI plannings, l’examen des problèmes ou des obstacles rencontrés pendant le PI, ainsi que la recherche de solutions et la définition des actions à entreprendre pour les résoudre.

La rétrospective du PI planning peut être animée par petits groupes travaillant sur des sujets spécifiques, mais elle peut également impliquer l’ensemble de l’équipe ou de l’ART, en particulier pour les sujets qui nécessitent une discussion collective et une prise de décision commune. Les actions à entreprendre peuvent être portées soit par le groupe de rétrospective lui-même, soit par l’ART dans son ensemble, en fonction de la nature et de l’ampleur des problèmes identifiés.

J’espère que ces réponses vous seront utiles. N’hésitez pas à me solliciter si vous avez d’autres questions !

Cordialement.

[Laurent]

Bonjour Pamela,

Vous pouvez utiliser le quiz suivant : https://crossinstitute.fr/courses/examens-blanc-scrum-league-a-passer-apres-vos-autres-cours

Vous avez de nombreuses questions d’entraînement

[Laurent]

Bonjour Olivier,

Merci pour cette question très pertinente. L’objectif d’une rétrospective de sprint dans la méthodologie Scrum est d’inspecter le sprint qui vient de se terminer et de planifier des améliorations à mettre en œuvre au cours du prochain sprint. Les éléments d’action qui sont identifiés pendant cette rétrospective sont souvent des améliorations de processus ou des tâches qui aideront l’équipe à travailler plus efficacement ou à mieux répondre aux besoins des clients.

Il est vrai que normalement, les éléments du Sprint Backlog sont dérivés du Product Backlog. Cependant, les éléments d’action de la rétrospective représentent une exception à cette règle. Ils ne sont pas vraiment des fonctionnalités du produit, mais plutôt des améliorations du processus de développement. Par conséquent, ils peuvent être ajoutés directement au Sprint Backlog du prochain sprint, sans passer par le Product Backlog.

Ceci dit, il est important de noter que les méthodes agiles, y compris Scrum, sont destinées à être adaptatives et flexibles. Chaque équipe peut adapter ces pratiques à sa situation particulière. Par conséquent, si dans votre contexte, il est plus logique d’ajouter ces éléments d’action au Product Backlog et de les incorporer ensuite dans le Sprint Backlog lors de la planification du sprint, c’est tout à fait acceptable. L’important est de s’assurer que ces améliorations sont prises en compte et mises en œuvre.

En fin de compte, la désynchronisation entre les deux backlogs que vous mentionnez peut être gérée par une bonne communication et coordination au sein de l’équipe. Il est important de garder à l’esprit que le but ultime est l’amélioration continue du processus de développement et de la qualité du produit.

J’espère que cela répond à votre question. N’hésitez pas si vous avez d’autres interrogations.

[Laurent]

Bonjour,

Effectivement, dans la méthodologie Scrum qui est largement utilisée dans le développement de logiciel, le Product Owner (PO) est généralement celui qui gère le Product Backlog de manière autonome. Le Product Backlog est une liste priorisée de fonctionnalités à développer pour le produit, et le PO est responsable de définir et de prioriser ces éléments.

L’équipe de développement, quant à elle, sélectionne du travail à partir du Product Backlog pour le Sprint Backlog lors de la réunion de planification du sprint. Une fois le Sprint Backlog défini, l’équipe de développement gère en effet ce dernier de manière autonome, en déterminant la meilleure manière d’atteindre les objectifs du sprint.

Ainsi, en se basant sur les pratiques Scrum, la réponse à la question du test serait plutôt que la structuration de l’équipe de développement permet de gérer de façon autonome le Sprint Backlog, et non pas le Product Backlog. Cependant, les responsabilités peuvent varier selon les organisations et la méthode de travail adoptée.

En ce qui concerne la deuxième partie de la question, livrer des incréments en s’inspirant des meilleures pratiques UX, cela peut également faire partie des responsabilités de l’équipe de développement, bien que l’UX soit souvent une compétence spécialisée qui peut ne pas être présente au sein de chaque équipe de développement.

La réponse qui est la plus proche du framework est donc la 1 bien qu’elle ne soit pas formidable je vous l’accorde 😊

[Laurent]

Bonjour Marlene,

Le certificat vient de vous être envoyé. Désolé du délais mais nous dépendons des certificateurs qui ont des délais long pour établir les certificats.

[Laurent]

Bonjour Nadine,

Il vous suffit de suivre ce tuto pour pouvoir traduire tout les quizs en français en utilisant directement le plugin Google translate.
https://www.scrum.org/support/using-google-translate-plug-take-assessments

Si vous avez besoin d’aide dites le moi je ferais une rapide visio pour vous aider.

Cdl

[Laurent]

Bonjour,

voici mes réponses:

1) La structuration de l’équipe de développement permet de :
– Gérer de façon autonome le Backlog Produit (Bonne réponse)
– Livrer des incréments en s’inspirant des meilleurs pratiques UX (mauvaise réponse)

LE PO est responsable du backlog produit ce qu’ils veulent dire par gérer de façon autonome cela signifie que l’équipe a toutes les compétences pour traiter de travail car ils sont pluridisciplinaires il ne faut pas le lire comme faire le boulot du PO 😊. La question est effectivement un peu subjective je vous l’accorde.

2) La réunion de sprint planning nécessite
– La présence de tous les membres de l’équipe scrum (mauvaise réponse)
– Le backlog produit (bonne réponse)

Si un membre de l’équipe de dev est malade la planning à tout de meme lieu 😊 par contre sans backlog impossible de travailler

3) Les priorités du Backlog Produit peuvent être modifiées par le Scrum Master :
– Vrai (mauvaise réponse)
– Faux (bonne réponse)

Oui je suis d’accord avec vous dans les fait le scrum master peut aider sur cette partie aussi meme si ce n’est pas la meilleure personne pour cela. Mais garder cette réponse pour l’examen scrum league car la bonne réponse de leurs coté est Faux c’est une erreur de leurs part.

[Laurent]

Le DoD (Definition of Done) est une description des critères qui doivent être remplis pour considérer un élément du sprint backlog. Elle est revue par l’équipe durant la rétrospective et peut donc évoluer dans le temps.

[Laurent]

Bonjour Diego,

Le refinement (ou grooming) peut se faire à n’importe quelle moment durant le sprint le but est de contextualiser, commencer a entrevoir ce qui risque d’arriver au prochain sprint afin d’être prêt le jour du sprint planning.
Il peut d’ailleurs y avoir plusieurs refinement durant le sprint si cela est nécessaire , ce qu’il faut éviter c’est que les équipes découvrent les US le jour du sprint dans ce cas les estimations seront très mauvaises.

J’espere avoir pu vous éclairer 😉

[Laurent]

Bonjour Karine,

Désolé de ma réponse tardive mais je n’avais pas recu la notification de votre message.
Vous pouvez repasser la certification mais il faudra malheureusement repayer un voucher.

cdl

[Laurent]

Bonjour Celine,

Merci pour votre question voici mes points:

– En cas de désaccord entre l’équipe Scrum et le PO concernant les priorités du Product Backlog, elle peut les contester auprès des parties prenantes : cela implique donc que l’on est en dehors du cadre Scrum qui indique que seul le PO est sensé être en relation directe avec les parties prenantes et qu’il est seul responsable du Product Backlog ?
En fait meme si le PO est “accountable” du Product backlog l’équipe peut contester certains choix auprès des parties prenantes, si ils arrivent à les convaincre de l’interet de la modification le PO pourra revoir ses priorités.

– Pour votre seconde question le po est bien accoutable mais il peut deleguer tout ou une partie de la gestion du product backlog, ce qu’il faut comprendre derriere cette question est plutot que l’equipe étant auto-organiser prendra autant d’éléments du Product backlog que nécessaire, ce n’est pas le PO qui doit leurs dire combien de US ils sont capable de traiter.

excellente journée

[Laurent]

Bonjour lucas,

Les demandes de token se font en envoyant un mail à contact@crossthink.fr

[Auteur]

Messages