Bonjour,
En testant le quiz du site coach Agile, j’ai mal répondu à la question suivante : Un product Owner doit-il créer des critères d’acceptation clairs et non ambigus pour chaque élément du backlog produit avant de pouvoir le proposer en sprint planning ?
La bonne réponse est non.
Pourriez-vous m’expliquer pourquoi ?
Merci
Je pense que dans ça, il y a la notion que tout ce qui se trouve dans un Product Backlog n’est pas nécessairement user-facing: taches techniques, documentation, autres…
Sur certains de ces items, des critères d’acceptation ne sont pas nécessairement utiles.
Donc pour toi, il y a une piège ici, sur le mot CHAQUE ?
Je me suis posé aussi cette question : est-ce que les critères d’acception peuvent être évolutives PENDANT le sprint ? Si on se rend compte qu’on a oublié quelque chose. Ou il est nécessaire d’attendre le prochain sprint pour intégrer les évolutions ?
Je pense que oui, mais sans explication de texte de leur part, c’est assez ambigu. Pour ton autre question… Peut être que tu pourrais te poser la question dans l’autre sens: Qu’est ce que tu gagnerais à attendre le prochain sprint pour intégrer ces nouveaux critères d’acceptations vs les changer maintenant ?
En situation réelle, cette situation nous est déjà arrivé. Ce sont des modifications mineures, aperçu assez en amont de la phase du développement et nous avons intégré directement dans le sprint en cours.
Et par instinct, j’aurais dit que si les modifications étaient majeures, intervenu à la fin du développement, je l’aurais laisser pour la prochaine fois comme une amélioration.
J’aimerais savoir plutôt, s’il y a un texte officiel sur ce sujet ? Dans la question en haut, est-ce que la piège peut être sur le mot AVANT ?
Le genre de question « Code de la route » 
Le problème peut venir du « Claires et non ambigus ». Une story n’est pas un cahier des charges.
Il peut venir aussi de « AVANT de les proposer en sprint planning ». Le PO peut proposer des story incomplète qui seront raffinées pendant le sprint planning.
Ouais, c’est clairement cradoc comme formulation…
"avant de pouvoir le proposer en sprint planning "
Pour moi il peut proposer des éléments en sprint planning même si ils ne sont pas finalisé, si c’est le cas il faut alors les finaliser pendant le sprint planning. Le périmètre doit être fixé a la fin du sprint planning, si le périmètre du sprint change en cours de sprint, il doit alors y avoir une renégociation entre po et développeurs.
Je viens de voir que Robin Béraud-Sudreau rejoint Scrum Life. Comme la question vient de son site, j’aimerais bien avoir ses lumières sur la question mais avons-nous une moyenne de tagger une personne une personne qui ne participe pas au feed ici ?
Je penses qu’il y a comme un piège dans la question.
On parle ici de proposer une US pour une Sprint Planning.
Le Sprint Planning étant un lieu où justement des US peuvent être affinée, les critères d’acceptation sont donc potentiellement revus, complétés ou amendées.
Donc il n’y a aucune obligation à ce que les critères d’acceptation soient désignés comme étant figés.
Il est à noter que les critères d’acceptation entrent dans la DOR d’une US.
Même si la question portait sur l’intégration de l’US au Sprint Backlog alors qu’elle n’est pas Ready, il est tout à fait possible d’accepter des US non Ready dans la mesure où des actions/ateliers sont prévus dans le Sprint pour l’affiner.
Naturellement, celà doit concerner un petit nombre d’US pour permettre à la DevTeam de démarrer le Sprint en attendant la maturation des US not Ready.
Néanmoins, ce sont des cas qui doivent rester tout même à la marge.
Il convient de tout mettre en place pour être dans les clous de la méthode Scrum à chaque itération.
@Hanh_NGUYEN peux-tu citer un passage du Scrum guide qui demande au PO d’écrire des critères d’acceptation clairs et non ambiguës ?
Les questions font référence à une certification donc les questions se basent, à ce niveau en tout cas, sur ce que dit le Scrum guide
C’est pas faux ça. Après, mon avis, c’est que de toute façon, c’est bien caca. 
J’ai pu échanger avec l’auteur hier
Moi, à cette question, pour un passage de certification Scrum d’autant plus, je dis non ! 
"The Product Owner is also accountable for effective Product Backlog management, which includes:
[…]
- Creating and clearly communicating Product Backlog items;
[…]- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
"
" Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
"
Selon moi et ma compréhension du Scrum Guide :
Pour moi donc, c’est clairement un non et en plus je pense que j’ai raison 
. @Rob1 t’en dis quoi, jsuis vraiment à côté de la plaque ? 
Dans mon équipe actuelle, il arrive que nous écrivions les critères d’acceptation de nos US avant le sprint, pendant le planning, pendant le sprint (dans le backlog de sprint). L’idée c’est qu’ils soient mis à jour à tout moment si nécessaire, les changements sont ainsi accueillis même tardivement tant qu’ils ne remettent pas en cause l’atteinte de l’objectif de sprint. Tout le monde met la main à la la pâte pour ces AC, PO, SM, Dev, les Parties Prenantes un peu aussi, à plusieurs, au moins en relecture. Si nous devions attendre que le PO écrive tous les AC des US, on aurait déjà plus de PO depuis un moment je pense donc ça participe à garder un rythme plus soutenable aussi (force à toi POW si tu passes par là 
) et aussi (voir surtout) on aurait livré peu de valeur. Même si ‹ sur le papier › le PO en reste imputable cela devient de plus en plus une responsabilité partagée, d’équipe et j’avoue que ça me plaît beaucoup 
(dis comme ça ça fait Bisounours, paradis tout le tralala, évidemment tout n’est pas parfait hein, sinon c’est moins drôle )
Bref, je répondrai non à cette question, jusqu’à ce qu’on me convainque que j’ai tort (Bon courage ).
Bonjour, comme le montre @SophieB si on se réfère au scrum guide, la réponse serait non.
Conceptuellement scrum est fait pour que les processus soit efficients(=efficaces).
La définition de l’efficacité est : « Caractère d’une personne, d’un organisme efficace, qui produit le maximum de résultats avec le minimum d’efforts, de moyens ; efficience, rendement : Un souci d’efficacité. »
Si on pousse a l’extrême l’hypothèse qui veut qu’un PO ne peut pas présenter au sprint planning des éléments non prêts. Il n’y aurait donc rien à présenter car rien de prêt. L’équipe serait alors bloquée. On est tout sauf dans un processus efficient.
D’un simple point de vue conceptuel la réponse est forcément non, car en désaccord total avec le but premier de scrum qui est d’avoir un processus efficient. Il faut a tout pris éviter les blocages. Tout doit être fluide.
