Voir la source de Ordonné et non priorisé

[[Category: Jim Coplien]]
[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
Auteur : Jim Coplien<br />
Source : [http://www.scrum.org/scrum-guide-updates#ordered Ordered Not Prioritized]<br />
Date : 02/08/2011<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 09/08/2011<br />
----
Traduction :<br />
<br /> 
''<span style="color: #808080">Le terme "Prioriser" a été retiré en faveur du terme "Ordonner"" pour organiser le Backlog Produit. Ken et Jeff ont demandé à Jim Coplien de donner des détails sur les raisons de ce changement :</span>''<br /> <br />  Par le passé, le Guide Scrum utilisait constamment le mot "priorité" pour le Backlog Produit ou indiquait que le Backlog Produit était "priorisé". Bien que le Backlog Produit doive être ordonné, le faire par ordre de priorité n'est qu'une des nombreuses techniques possibles, et rarement la meilleure. Le nouveau Guide Scrum utilise plutôt le terme ordonné pour le Backlog Produit. Cela reflète une profonde compréhension de la part des nombreux meneurs de la communauté Scrum. Tentons de clarifier la raison de ce changement.<br /> <br />  Prioriser une liste signifie qu'il faut ordonner ses éléments en fonction de leur importance relative les uns par rapport aux autres. Par définition, les priorités conduisent à comparer les éléments d'une liste deux par deux. Pensez à utiliser le [http://fr.wikipedia.org/wiki/Tri_%C3%A0_bulles tri à bulles] pour prioriser le Backlog Produit : comparez les deux premiers éléments<sup class="reference">[1]</sup> et échangez-les s'ils sont dans le mauvais ordre, passez ensuite sur les deux éléments suivants, et bouclez ainsi sur la liste jusqu'à ce que tout soit à sa place. Prioriser et trier vont de pair. Toutes les comparaisons sont locales. Ce processus est analogue à l'optimisation locale.<br /> <br />  Plus largement, l’Équipe Scrum et le Product Owner en particulier, ont besoin de considérer le Backlog Produit dans sa globalité lorsqu'ils ordonnent ses éléments, afin d'optimiser la valeur ou le retour sur investissement (ROI). La plupart des gens pensent généralement que le ROI correspond à la priorité ; mais vous devez considérer le ROI comme un résultat à long terme issu de l'ensemble du Backlog Produit plutôt qu'à partir de la somme des ROI de chacun de ses éléments<sup class="reference">[2]</sup> . C'est en partie vrai parce que le ROI de chaque élément dépend de sa position dans le backlog. Par exemple, disons que vous avez un élément du Backlog Produit qui consiste à faire danser des Pères Noël sur l'écran d'accueil d'un site web. Cet élément générera pas mal de ROI à la fin de Novembre et au mois de Décembre, mais beaucoup moins en Juillet ou même au mois de Janvier suivant. Déplacer cet élément dans le backlog modifie son ROI (ou, plus généralement, tout autre critère ayant un impact sur l'ordre), car le repositionner dans le backlog modifie sa date de livraison. Même les déplacements causés par le tri à bulles feront que la "priorité" des éléments du Backlog Produit change dû à un effet secondaire de la technique de priorisation elle-même.<br /> <br />  Le Backlog Produit doit en effet être ordonné, ce qui détermine l'ordre de livraison des éléments du Backlog Produit. L’Équipe de Développement peut discuter avec le Product Owner de l'ordre des éléments du Backlog Produit, mais, à la fin, l’Équipe de Développement doit respecter et prendre les éléments dans l'ordre du Backlog Produit. Même s'il n'est pas garanti que les éléments du Backlog Produit aient été ordonnés par valeur ou priorité. Vous ne pouvez pas assigner des priorités aux éléments du Backlog Produit - qu'elles proviennent d'un ROI, de l'importance pour l'entreprise, ou d'où que ce soit - et ensuite prioriser le backlog sur la base de ces valeurs relatives. Vous devez considérer la globalité des éléments du Backlog Produit.<br /> <br />  Disons que vous construisez une maison dans les tropiques, votre objectif principal est de rester abrité de la pluie qui tombe tous les après-midis. Vous envisagez une maison avec des murs, des fenêtres et des portes, mais c'est vraiment le toit qui vous intéresse. Vous construisez un Backlog Produit pour votre maison. Allez-vous mettre le toit en premier ? Ce serait un backlog priorisé. Mais ce que vous allez plutôt chercher à faire c'est d'ordonner le backlog pour générer le plus grand ROI à long terme. Les mêmes principes s'appliquent également au ROI à court terme... pour ce que ça vaut. Pour ce faire, vous allez acquérir une connaissance profonde de l'entreprise, du marché, des dépendances entre les éléments du Backlog Produit, la connaissance de l'évolution et des conditions du marché des fenêtres, de l'état de la chaîne d'approvisionnement, et d'une foule d'autres détails qui sont beaucoup trop complexes pour être gérer au travers d'un simple tri à bulles.<br /> <br />  Pour pouvoir utiliser le terme "Ordonner" au lieu de "Prioriser", il est clair que le Product Owner doit prendre des décisions. Il ne peut pas simplement dire "Ces cinq éléments ont tous la priorité 1, ces trois éléments ont la priorité 2" et ainsi de suite. Le Product Owner doit fournir un Backlog Produit totalement ordonné.<br /> <br />  Bien sûr, vous pouvez utiliser la priorisation, car elle reste une technique parmi d'autres d'ordonner les éléments. Ordonner les éléments du Backlog Produit par leur "priorité" conduit à sous-optimiser la valeur du marché et à réduire le ROI global. Jeff Sutherland dit souvent que vous pouvez doubler le ROI en réordonnant le backlog. Habituellement, le meilleur ordre n'est pas l'ordre des priorités. Il y a des exceptions lorsque vous ordonnez le backlog par la priorité du ROI, en particulier lorsque vous contractualisez au forfait avec des clients : voir <span class="wiki_link_ext">[[Le%20changement%20est%20gratuit|LE CHANGEMENT EST GRATUIT]]</span> et [[De%20l%27argent%20pour%20rien|DE L'ARGENT POUR RIEN]]. Toutefois, il s'agit d'un contexte très particulier pour des forfaits à coût fixe et parfois même périmètre fixe. Cela reste des exceptions, et le Guide Scrum ne préconise pas et ne devrait pas préconiser leur usage, ni la technique de priorisation qui les accompagne. Plus généralement, vous utiliserez un ordre non priorisé. Inspectez et Adaptez.<br /> <br /> <span style="color: #808080">Copyright © 2011, Scrum.org. All rights reserved.</span><br />
----

# NdT : ce qui me fait clairement penser à la Vision 20/20 des Innovation Games de Luke Hohmann.
# NdT : l'ensemble est supérieur à la somme des parties.