À la création d'un projet de type Scrum, Nutcache crée automatiquement un premier artéfact appelé "Gestion du backlog". C'est à partir de cet artéfact que vous construirez votre backlog produit.




Petit rappel
Qu'est-ce que le backlog produit? En quelques mots, le backlog produit consiste en une liste priorisée des exigences fonctionnelles et non fonctionnelles (les stories) du produit à développer en fonction de la vision ou l'objectif que le projet doit atteindre.


La définition des personas

Afin d'être ne mesure de formaliser la vision du produit que l'on souhaite réaliser en fonction des exigences du commanditaire du projet (sponsor), il est important de bien identifier puis détailler tous les intervenants impliqués dans l'utilisation finale du produit. Cette étape consiste à définir les personas. 


Un persona constitue l'archétype d'un utilisateur, ou en d'autres mots, une représentation fictive d’un utilisateur cible que vous pouvez utiliser afin de vous aider dans la prise de décisions sur le produit, le design, les fonctionnalités, etc. Les stories incluses dans la liste de personas représentent donc des personnages fictifs créés pour représenter les spécificités d’un groupe d’utilisateurs. Les différents personas vous permettent de définir très précisément le profil de vos utilisateurs :


  • âge
  • milieu socio-professionnel
  • secteur d'activité
  • habitudes
  • comment l'utilisateur utilisera le système
  • fréquence d'utilisation du système
  • valeur commerciale
  • etc.


Après avoir créé tous les acteurs impliqués dans l'utilisation du système à partir de la liste prédéfinie et identifiée "Personas", il sera beaucoup plus facile de définir les fonctionnalités à développer (les stories) afin de rencontrer l'objectif du produit.



La création des stories dans la liste Backlog

La vision du produit définie, les personas identifiés, l'étape suivante consiste à créer les stories à partir de la liste Backlog. Règle générale, la construction du backlog est collaborative, c'est-à-dire qu'elle implique le Product Owner et l'équipe de développement. Le backlog n'est pas un document figé; il sert à guider l'équipe de développement et peut évoluer tout au long du projet, c'est-à-dire que vous pouvez y modifier, retirer ou ajouter des stories en cours de route.


Cliquez sur le lien +Story pour ajouter une nouvelle story :



Le premier onglet de la story vous invite à d'abord y entrer une description, c'est-à-dire en quoi consiste cette story. 



Ensuite, vous pouvez compléter les champs suivants :


  • Valeur métier : plus la valeur métier d'une story est élevée, plus grande sera sa priorité lorsque le temps viendra de prioriser les stories.
  • Complexité : l'échelle de complexité reprend la suite de Fibonacci et permet l'évaluation de la charge de travail à effectuer.
  • Retour sur investissement : la valeur du retour sur investissement est obtenue par la division de la valeur métier de la story par son niveau de complexité.


Les autres champs du premier onglet seront abordés lors de l'attribution des stories dans le cadre du déroulement du sprint : 

  • Durée estimée : représente le nombre d'heures estimées pour compléter la story.
  • Durée : représente le nombre d'heures exactes consignées sur cette story via les entrées de temps.
  • Élément de projet : associer un élément de projet à une story permet d'y consigner le temps travaillé et ainsi affecter le budget du projet.
  • Date de début prévue : représente la date prévue à laquelle les membres de l'équipe aborderont cette story.
  • Date de fin prévue : représente la date prévue à laquelle la story sera complétée.
  • Date de début : représente la date réelle à laquelle les membres de l'équipe ont débuté le travail à effectuer.
  • Date complétée : représente la date à laquelle la story a été complétée véritablement.


Les autres onglets de la story seront également abordés dans le cadre du déroulement du sprint.


La priorisation des stories

Le Product Owner a pour tâche de classer par priorité et de définir l'ordre de réalisation des stories. Une façon de prioriser les stories est d'utiliser la valeur métier de chacune d'elle. L’attribution d’une valeur métier par le Product Owner à chacune des stories permet d’en définir l’importance relative et ainsi aider à la priorisation du backlog, d’autant plus que la valeur métier d’une story divisée par sa complexité permet d’en connaître le ROI. La valeur ROI, quant à elle, est d’une importance significative dans la gestion du backlog puisqu’elle permet de prioriser les stories dont les valeurs métier seraient égales.



La Sandbox 

Les stories incluses dans la liste Sandbox représentent un ensemble de tâches suggérées. Voyez la liste Sandbox comme une aire d’attente où vous ajoutez des idées à valider et éventuellement à inclure dans la stratégie de développement de votre produit. Une fois acceptée, ces stories peuvent être déplacées vers le Backlog par un simple glisser/déposer.


La Icebox

Les stories incluses dans la liste Icebox représentent un ensemble de tâches sur lesquelles vous ne prévoyez pas travailler à court terme, mais que vous désirez tout de même conserver. Généralement, cette liste est composée de bogues de faible priorité ou de fonctionnalités de faible valeur qui sont couramment demandées. Une fois acceptée, ces stories peuvent être déplacées vers le Backlog par un simple glisser/déposer.


Après avoir complété le backlog produit, l'étape suivante consiste à créer le premier sprint, c'est-à-dire l'itération pendant laquelle les membres de l'équipe vont concevoir, réaliser et tester les fonctionnalités à développer.