Les 7 différences entre priorité et sévérité

En théorie, les différences en priorité et sévérité sont simples à comprendre.

Dans la réalité, on a souvent tendance à s’embrouiller entre les deux.

Dans ce post, je reviens aux bases et je vous explique les 7 différences entre priorité et sévérité.

1. Priorité : Une affaire de business

La priorité, comme vous devez déjà le savoir, s’évalue en fonction de la valeur business.

Par exemple, si en tant que product owner vous êtes responsable de la KPI acquisition utilisateur, alors toutes les US ou bugs à résoudre qui ont un impact de près et même de loin sur cette KPI devront avoir une priorité haute.

2. Sévérité : Une affaire de fonctionnel

La sévérité se fiche pas mal de la valeur business.

Elle s’évalue uniquement sur l’urgence fonctionnelle.

Par exemple, si une action particulière engendre une erreur 500 ou casse tout votre application, alors la sévérité sera jugée critique.

Pour comprendre la notion de sévérité il faut comprendre la notion de contournement.

  • Si l’utilisateur rencontre un problème dans l’application mais peut le contourner par différents moyens, alors la sévérité sera jugée basse ou moyenne.
  • Si l’utilisateur rencontre un problème dans l’application qui le bloque totalement dans son utilisation, alors la sévérité sera jugée haute.

Exemples de haute sévérité :

  • L’utilisateur doit quitter l’application et la redémarrer pour l’utiliser.
  • Page web inaccessible

3. La sévérité est associé au bug uniquement

C’est évident mais je préfère le rappeler au cas où, la sévérité ne s’applique qu’à des bugs.
Il n’est pas possible de mettre une sévérité à une user story car l’US décrit toujours un scénario idéal (sans bug évidemment).

A l’inverse la priorité s’applique à la fois à une US mais aussi un bug.

En effet, lorsqu’un bug est reporté, il s’inscrit dans une logique business qui doit être priorisé pour déterminer l’urgence de sa résolution

4. C’est le testeur qui détermine le niveau de sévérité

En tant que PO, vous n’êtes (normalement) pas en charge d’évaluer la sévérité d’un bug.

C’est le boulot du testeur car c’est lui qui déniche la majorité des bugs

En revanche, vous avez le droit de reporter des bugs quand vous en trouver un.
Dans ce cas, vous pouvez ajouter la sévérité.

5. C’est le PO (et lui seul) qui détermine le niveau de priorité

Ça tombe sous le sens, mais je préfère le rappeler car j’ai déjà rencontré des cas où les testeurs indiquaient une priorité aux bugs qu’ils relevaient.

Mettez les choses au clair avec votre testeur pour lui indiquer le process et la limite entre votre rôle et le sien. Si vous voulez en savoir plus, j’en parle ici.

6. La sévérité ne doit pas influencer la priorité

Voici l’erreur classique.

Votre testeur vous reporte un bug avec une sévérité S1 (critique).
Dans l’urgence et par manque d’analyse, vous lisez le bug brièvement et vous lui mettez une priorité 1 car vous vous laissez influencer par la valeur de la sévérité.

Cette situation est la raison pour laquelle j’écris ce mini-post.

NE PRENEZ JAMAIS EN COMPTE LA VALEUR DE LA SÉVÉRITÉ POUR ÉVALUER UNE PRIORITÉ.


Voici un exemple concret :

  • Imaginez que votre testeur vous signale un bug qui décrit le scénario suivant :
  • Au clic sur un lien dans un email envoyé à l’utilisateur, la redirection retourne sur une page 404.
  • L’utilisateur ne peut pas revenir en arrière car il n’y a pas de logique de navigation dans un scénario de deeplink

Oui mais,

  • En analysant 2 minutes le scénario décrit dans le bug, vous remarquez que cet e-mail est envoyé à 0,01% de votre base utilisateur mensuellement.
  • En gros cet email ne sert à rien et devrait être certainement retiré des automatisations.
  • Dans ce cas, vous ne pouvez pas donner une priorité 1 car la valeur business est insignifiante comparé à d’autres priorités.

Vous avez d’autres chats à fouetter.

7. Le petit truc pour ne pas être influencé par une sévérité 

Lorsque votre testeur vous signale un bug, demandez lui toujours de vous retrouver l’US ou l’epic associée à ce bug.

En effet, un bug est en principe toujours associé à une fonctionnalité qui a été précédemment pensée et priorisée dans votre outil de gestion de projet agile.

En liant le bug à l’US originale, vous retrouverez immédiatement le contexte et cela vous permettra de prioriser ce bug plus justement.

La sévérité n’est pas votre KPI

Concepts simplissimes et grande confusion.

Confondre la priorité avec la sévérité, c’est comme confondre vos problèmes avec ceux des autres.

Comme le reste des stakeholders, les testeurs sont là pour vous communiquer leurs priorités.
La sévérité permet de vous mettre la pression et vous rappeler l’urgence d’un point de vue.
A vous de les pondérer.

Vous êtes le chef d’orchestre du produit, vous devez gérer tous les problèmes rencontrés et objectifs imposés afin de les analyser pour en sortir VOTRE liste de priorité.

Prenez juste les sévérités comme une information supplémentaire à ajouter dans votre brainstorming interne.

Ne vous laissez pas influencer par leur barème d’urgence similaire à celui de vos priorités.

2 Replies to “Les 7 différences entre priorité et sévérité”

Laisser un commentaire

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