En tout cas, je suis bien content que ma question entraine tous ces échanges. 
1 « J'aime »
Bonjour,
Je suis en pleine réflexion et teste sur le sujet.
Pourquoi une DoR ? Que serait-elle ?
Je fixe une première règle, une DoR ne doit pas empêcher le travail de commencer.
La seconde règle, une DoR doit aider l’équipe à mieux identifier le travail à faire.
Et finalement la DoR, ne serait-elle pas une liste de question à se poser entre nous pour mieux identifier les zone d’ombres et de façon plus efficace ?
Mais c’est clairement dangereux, et je le répète à chaque fois qu’on le remet sur la table.
Il y a un besoin, quelque chose de sous-jacent. Est-ce que la DoR n’est pas le chemin vers l’identification de la cause racine ? Avons-nous besoin de travailler sur une DoR pour trouver, apprendre ?
Arf, suis-je un (bon) coach ? Ou un tortionnaire ?
Le mythe de la « cause racine ». Dans un système complexe, il n’y a pas une cause racine pour un problème. Le but de la méthode est seulement d’explorer le domaine du problème. C’est une heuristique, qui est malheureusement pas exempt de défauts.
Oui, l’expérience montre que ce n’est pas si simple. 
Moi je suis d’un avis à contre-courant.
Et je regrette que la DoR ne soit pas mentionnée explicitement dans le SCRUM guide, même si Jeff Sutherland l’y sous-entend dans une ancienne vidéo youtube « Scrum: What it does mean to be Ready-Ready? ».
Je vois la DoR comme un minimum d’éléments que l’équipe définit (voir le lien avec U-INVEST) pour pouvoir répondre à la question « Avons-nous assez d’éléments pour clairement identifier la juste plus-value business qui devra être apportée ? ». A défaut Garbage-IN, Garbage-OUT.
C’est selon moi, un médium par lequel l’équipe se doit de se faire respecter au lieu de produire à tout va contre vent et marée. Le scrum Master se doit d’être le garant, en aide au PO, pour ne faire rentrer en candidat dans le backlog que des demandes saines.
C’est pas de la bureaucratie, mais de l’efficience de talents en imposant un minimum de discipline.
1 « J'aime »
En tout cas, c’est dans ton sens que je vais.
Avoir une liste de points d’attention pendant l’affinage, une liste de question, c’est super.
En faire une liste de « si je ne l’ai pas, je ne suis pas prêt », non.
Je viens encore de voir une équipe chez nous qui précise que la découpe en tâches techniques doit être faite pour que la story soit « prête ».
Quelle source de gaspillage.
Vu les avis dans tous les sens sur cette discussion, je pense qu’il n’y ai pas un courant et un contre-courant. 
En ce moment et j’en parlais avec SAFe la semaine passée, j’ai envie de mettre du chapeau de E.d.Bono partout.
On pourrait essayer de faire de même ici
flag: g: je pense que
: j’ai peur que, attention à
organisons nous pour
Ca va être génial si
Il est un fait que
En l’état on peut donc
2 « J'aime »
Mes deux centimes sur la question.
Je suis assez raccord avec les personnes qui pensent que la DOR est un obstacle. En tout cas dans la manière dont la DOR est habituellement présentée. La DOR s’appuie sur l’idée qu’il existe une charge de travail en amont de l’inclusion du PBI dans le sprint. Il y aurait donc une charge de travail avant le sprint, ce qui constitue un anti-pattern par rapport à Scrum : tout le travail devrait se faire dans le sprint.
Au delà de la posture « c’est qu’un outil, il n’est pas mauvais ou bon en soi, ne jetez pas l’eau du bain avec le bébé », personnellement, je cherche encore ne serait-ce qu’un exemple crédible de critère de DOR qui résoudrait un problème de l’équipe de développement. Je n’en ai jamais trouvé. Je constate qu’une analyse avec toute l’équipe en sprint planning est nettement plus productive que des sessions de raffinement. Ne parlons même pas d’une étude « technique » en amont par le PO qui se transforme en petit BA.
Si on doit répliquer le fonctionnement de la DOD pour une DOR, alors à mon avis il faut prendre le problème à l’envers. De la même manière que l’équipe de développement définit sa DOD pour déterminer à quelles conditions elle considère son travail de développement terminé, la DOR pourrait être déterminée par le PO pour déterminer à quelles conditions il ou elle considère l’analyse marketing comme terminée :
- étude de marché ?
- hypothèse d’adoption à T+3M ?
- niveau de risque ?
- enjeu financier ?
- soutien politique ?
- …
Ca prend d’autant plus de sens si le PO a délégué certaines responsabilités de la discovery pour aligner son équipe produit. Une fois toutes ces étapes passées, le PO peut alors rédiger son PBI et le prioriser au sein du journal produit.
Pour info, on répond à un compte « supprimé »
Mais l’échange reste intéressant