La valeur métier est-elle suffisante pour prioriser le backlog ?

((/dotclear/public/logos/scrumdesk-logo.gif|Logo ScrumDesk|L|Logo ScrumDesk))J’ai traduit ce billet de ScrumDesk ++[« Is business value enough for backlog prioritization ? »|http://www.scrumdesk.com/is-business-value-enough-for-backlog-prioritization/|en]++. Il a le mérite de montrer l’interdépendance des critères de priorisation. ScrumDesk est un outil agile de pilotage de projet, concurrent de ++[IceScrum|http://www.icescrum.org/]++ (par exemple).%%% > Les coachs Agile enseignent aux équipes à développer selon la __valeur métier__ qui doit être livrée en fin du sprint.%%% > %%% > Mais une valeur peut-elle constituée un indicateur de priorité ? Oui, mais pas à elle seule. Il y a beaucoup d’autres critères que nous oublions souvent de prendre en considération.%%% > %%% > Nous vous invitons à adopter une approche différente. Nous souhaiterions pouvoir calculer la priorité selon la valeur métier, mais en tenant également compte du risque et de l’effort. De cette façon, nous pouvons obtenir une priorité plus précise, autrement dit pas seulement basée sur une conjecture.%%% > %%% > ((/dotclear/public/traductions/SD-PriorityCalculation.png|Calcul de la priorité||Calcul de la priorité))%%% > %%% > Souvent, les Product Owners ne considèrent que la __Valeur Métier Positive__. Il s’agit de la valeur dont l’entreprise bénéficiera si la story est livrée. Mais il existe aussi une __Valeur Négative__ qui peut générer des pertes ; par exemple, il n’est pas logique de devoir se reconnecter lorsque vous passez d’une page à l’autre.%%% > %%% > Le facteur __Risque__ ne doit pas être oublié. Vous pouvez mettre en œuvre la gestion des risques de différentes manières ; par exemple, selon une échelle Haut->Bas ou en numérotant les niveaux de risque. Plus la story est risquée, plus la priorité est haute.%%% > %%% > Le facteur __Dépendances__ est le nombre de relations avec les autres stories. Plus il y a de dépendances, plus la priorité est haute puisque le problème semble être plus complexe.%%% > %%% > Le facteur __Effort__ rend la priorité non-linéaire. Ce qui est plus petit peut être fait plus tôt car cela peut être estimé beaucoup plus précisément. Les grosses stories sont typiquement des epics qui doivent par conséquent être mieux détaillées puisqu’elles ne sont pas prêtes pour être implémentées.%%% > %%% > ScrumDesk a mis en œuvre cette approche après avoir collaboré avec ses meilleurs clients. Nous avons appris à appliquer cette démarche dans l’élaboration de nos backlogs produits. Cela nous aide à confirmer notre intuition de la priorité lorsqu’on la compare à la priorité calculée.%%% > %%% > Nous prenons en compte cette priorité calculée dans l’estimation de l’__Importance__ de la story.%%% > %%% > ((/dotclear/public/traductions/SD-Priority1.png|Story 5401 : calcul de la priorité||Story 5401 : calcul de la priorité)) —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *