Toutes mes réponses sur les forums
-
AuteurMessages
-
Laurent
Maître des clésBonjour,
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
Maître des clésLe 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
Maître des clésBonjour 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
Maître des clésBonjour 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
Maître des clésBonjour 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
Maître des clésBonjour lucas,
Les demandes de token se font en envoyant un mail à contact@crossthink.fr
Laurent
Maître des clésBonjour Karine,
Les enablers ont été popularisé avec le framework SAFe. Cependant, ce concept portant parfois d’autres noms, est parfois une réponse pour des équipes en recherche de solutions pour rendre leurs « user-stories » indépendantes.Les enablers sont des items du backlog qui prennent en charge les activités nécessaires pour amener les architectures à être opérationnelles pour créer les fonctionnalités futures. Ces items peuvent représenter :
de l’exploration
de l’évolution d’infrastructures
de la conformité
de l’évolution des architectures
Il faut cependant faire attention de ne pas utiliser ces enablers pour prévoir des mois de user-stories. Ces enablers doivent être utilisés pour rendre les user-stories du prochain sprint ou du sprint en cours indépendante.Laurent
Maître des clésBonjour Kaori,
Effectivement ils ont changé la tournure de phrase mais cela reste equivalent il s’agit bien de la scrum team entière qui ne doit pas dépasser 10 personne et inclus donc le PO et le SM.
Laurent
Maître des clésBonjour,
le test fait partie intégrantes du sprint il faut donc quand dans le sprint planning le test soit prit en compte.
Une US ne peut être considéré terminé sans qu’aucuns tests n’aient été fait.cdl
Laurent
Maître des clésBonjour Yannick,
Le but du PI planning étant de pouvoir synchroniser les équipes je dirais qu’il est necessaire de les faire. Par contre le framework prevoit toutes les 8 semaines. Toutes les 5 semaines cela me parait trop court.
Excellente soirée
-
AuteurMessages