logo

Fiche explicative Priorisation du backlog

Cette fiche explicative présente les principes et les règles pour prioriser le backlog produit.

1

Lexique

  Backlog ou Backlog produit : représente l’ensemble des besoins recueillis pour créer le produit désiré (application, site web…). Il est composé d’User Stories User story ou US (aussi appelé Ticket) : décrit une fonctionnalité ou une partie d’une fonctionnalité. Tâche : action à réaliser liée généralement à une User Story. Il peut s’agir du découpage d’un développement à réaliser, d’une tâche de test, d’un bug à corriger, … Prioriser : choisir la priorité de développement entre les User Stories. Priorité urgente (Urgent) : Utilisé pour les backlogs avec un niveau de complexité ou impact technique très fort. Ce niveau est à utiliser avec parcimonie. Priorité haute (high) : niveau de priorité le plus important. Les User Stories avec une priorité haute sont développées en début de projet. Cette priorité est utilisée pour les besoins les plus importants et/ou pour les besoins incertains demandant une validation des hypothèses auprès des utilisateurs (identifier tout de suite s’il est nécessaire de faire pivoter le projet ou non). Priorité moyenne (Medium) : niveau de priorité moyen. Les User Stories avec une priorité moyenne sont développées en milieu de projet. Cette priorité est utilisée pour les besoins principaux et/ou pour les besoins avec une certitude modérée quant aux hypothèses prises. Priorité faible (Low) : niveau de priorité le moins important. Les User Stories avec une priorité faible sont développées en fin de projet. Cette priorité est utilisée pour les besoins les moins importants et/ou pour les besoins certains ne demandant pas de validation d’hypothèse.   Product Owner : personne en charge de la vision du produit. Il se charge de créer et gérer le backlog. Il prend les décisions sur les priorités des User Stories et sur les User Stories à développer pendant les sprints. Affinage : cérémonie Agile pendant laquelle l’équipe de développement (et de test, si elle existe) estime le temps nécessaire pour réaliser des User Stories identifiées. Cette réunion est l’occasion pour l’équipe de poser ses questions au Product Owner et de lever des manquements dans les User Stories.   Sprint : cycle de développement court permettant de développer un nombre fini d’User Stories documentées et affinées. Une fois défini, un sprint ne peut pas être modifié. Plane.so : outil numérique permettant, en autre, de formaliser et gérer le backlog de votre projet.

2

Pourquoi prioriser le backlog ?

  Le backlog recense les User Stories à développer dans le cadre d’un projet. Ces User Stories sont ajoutées par le Product Owner au fur et à mesure de la formalisation du projet. Prioriser le backlog est essentiel afin de définir les User Stories à développer en priorité par rapport aux autres. Le choix de la priorité se porte notamment sur ces critères : Importance du besoin par rapport aux autres besoins Nécessité technique de mettre en place une User Story avant d’autres Nécessité fonctionnelle de mettre en place une User Story avant d’autres La majorité des projets nécessite une base technique afin de lancer les premiers développements fonctionnels. Il est courant que des User Stories techniques soient priorisées en premier afin de les développer lors des premiers sprints.   La finalité de la priorisation du backlog est la suivante : Identifier les User Stories les plus prioritaires afin de s’assurer de créer le plus de valeur possible dès les premiers développements Décrire et documenter les User Stories prioritaires afin de les rendre disponible à l’équipe pour l’affinage et le développement (sprint)   Il est à noter que le backlog est dit « vivant ». Il n’est jamais figé. Prioriser une User Story comme prioritaire à un moment « T » ne veut pas dire qu’elle ne peut pas changer de priorité.   Note d’attention pour le projet « au forfait » : étant donné le caractère fini du contrat il ne sera pas possible d’ajouter indéfiniment de nouvelles fonctionnalités. L’ajout de nouvelles fonctionnalités est négociable (ajout contre retrait d’autres fonctionnalités prévues) et doit être discuté avec le Product Owner. Si besoin, un devis complémentaire vous sera remis pour réaliser ses nouvelles fonctionnalités.

## Pourquoi prioriser le backlog ?   Le backlog recense les User Stories à développer dans le cadre d’un projet. Ces User Stories sont ajoutées par le Product Owner au fur et à mesure de la formalisation du projet. Prioriser le backlog est essentiel afin de définir les User Stories à développer en priorité par rapport aux autres. **Le choix de la priorité se porte notamment sur ces critères** : Importance du besoin par rapport aux autres besoins Nécessité technique de mettre en place une User Story avant d’autres Nécessité fonctionnelle de mettre en place une User Story avant d’autres La majorité des projets nécessite une base technique afin de lancer les premiers développements fonctionnels. Il est courant que des User Stories techniques soient priorisées en premier afin de les développer lors des premiers sprints.   **La finalité de la priorisation du backlog est la suivante** : Identifier les User Stories les plus prioritaires afin de s’assurer de créer le plus de valeur possible dès les premiers développements Décrire et documenter les User Stories prioritaires afin de les rendre disponible à l’équipe pour l’affinage et le développement (sprint)   Il est à noter que le backlog est dit « vivant ». Il n’est jamais figé. Prioriser une User Story comme prioritaire à un moment « T » ne veut pas dire qu’elle ne peut pas changer de priorité.   Note d’attention pour le projet « au forfait » : étant donné le caractère fini du contrat il ne sera pas possible d’ajouter indéfiniment de nouvelles fonctionnalités. L’ajout de nouvelles fonctionnalités est négociable (ajout contre retrait d’autres fonctionnalités prévues) et doit être discuté avec le Product Owner. Si besoin, un devis complémentaire vous sera remis pour réaliser ses nouvelles fonctionnalités.
3

Comment est priorisé le backlog ?

 

Priorisation avec Plane.so Le backlog est créé et géré dans Plane.so. Un accès à cet outil en ligne vous sera donné au lancement du projet. Depuis cette interface, il vous sera possible d’ajouter et modifier Features et User Stories. Ces éléments constituent le backlog du projet.   Vous pouvez consulter le backlog à tout moment sur Plane.so : Accéder à Plane.so : choisir le projet. Ici dans l’exemple le projet se nomme “MG”  

## Comment est priorisé le backlog ?   Priorisation avec Plane.so Le backlog est créé et géré dans Plane.so. Un accès à cet outil en ligne vous sera donné au lancement du projet. Depuis cette interface, il vous sera possible d’ajouter et modifier Features et User Stories. Ces éléments constituent le backlog du projet.   Vous pouvez consulter le backlog à tout moment sur Plane.so : Accéder à Plane.so : choisir le projet. Ici dans l’exemple le projet se nomme “MG”  
5

Vous pouvez définir la priorité d’un backlog en choisissant parmi les choix de priorité : Vous pouvez regrouper les backlogs en fonction de leur priorité en utilisant le menu “display” :

Vous pouvez définir la priorité d’un backlog en choisissant parmi les choix de priorité : Vous pouvez regrouper les backlogs en fonction de leur priorité en utilisant le menu “display” :
6

Recommandations et comprendre comment le backlog est prioriser Mettre en priorité supérieure une User Stories nécessitant le développement d’une autre US qui a une priorité plus basse. Il est conseillé de toujours identifier les liens entre les US s’il y en a. Le bon réflexe est d’aller sur “Add relation”. Cela facilitera le travail de définition des sprints pour le Product Owner.

**Recommandations et comprendre comment le backlog est prioriser** Mettre en priorité supérieure une User Stories nécessitant le développement d’une autre US qui a une priorité plus basse. Il est conseillé de toujours identifier les liens entre les US s’il y en a. Le bon réflexe est d’aller sur “Add relation”. Cela facilitera le travail de définition des sprints pour le Product Owner.
7
  • Vouloir finaliser les développements liés à une feature à tout prix en mettant en priorité ‘’Haute’’ toutes les User Stories liées à cette feature est souvent une erreur. En effet, il faut toujours se concentrer sur la valeur apportée réellement à l’utilisateur par l’User Story et/ou la criticité de l’hypothèse à valider auprès de l’utilisateur.   Exemple : Feature : Authentification de l’utilisateur US 1 : Inscription de l’utilisateur => cette priorité, selon le projet et la volumétrie des utilisateurs, peut être moyenne ou de priorité basse (les premiers utilisateurs pouvant être ajoutés manuellement en base de données). US 2 : Connexion de l’utilisateur => nécessite généralement une priorité haute US 3 : Déconnexion de l’utilisateur => nécessite généralement une priorité haute US 4 : Modification de l’email lié à un compte => cette fonctionnalité est de priorité très basse  
  • Ne pas documenter/rédiger une User Story de priorité haute est une erreur. En effet, si elle n’est pas documentée l’User Story ne pourra pas être étudiée lors d’un affinage par l’équipe de développement (et de test si existante). L’ordre des priorités doit être utilisé comme ordre de rédaction des User Stories.   – Au lancement d’une application, les tâches d’automatisation qui sont réalisables manuellement doit être de priorités faibles. Exemple : Feature : Envoyer le dernier article du blog aux utilisateurs via une newsletter. Cette tâche peut être faite manuellement par une personne l’entreprise sur base d’une extraction des emails des utilisateurs depuis la base de données.