Gérer le backlog

Vous pouvez utiliser le Case Type Backlog (issu de la phase de Découverte (Discover) ) comme point de départ pour votre backlog du projet. Il contient déjà de la documentation pour de nombreux éléments amenés à devenir des user stories et des epics.  

Par ailleurs, vos sessions dédiées à la stratégie de conception ont pu faire émerger des idées innovantes dans le cadre d’un design sprint. Le Case Type Backlog et les sessions de conception fournissent les informations nécessaires pour remplir le backlog deu projet pendant la phase de Préparation (Prepare).

Au cours de la phase de préparation, l’équipe projet (avec des représentants IT et métier) travaille de manière collaborative pour ajouter des informations dans le backlog de type de dossier (Case Type) afin de créer l’ébauche de types de dossier de haut niveau documentés à l’aide des outils Pega.  Ce travail collaboratif permet d’identifier les phases (stages) et étapes (steps) clés des types de dossier (Case Type) et d’y associer les aspects détaillés de chaque dossier (Case), comme les interfaces et les personas. Avec ces informations supplémentaires, l’équipe peut se concentrer sur les fonctionnalités nécessaires à l’obtention des résultats métier et dispose d’une base pour la priorisation des tâches.

L’image suivante montre comment les informations enregistrées dans le Case Type Backlog et les résultats d’un design sprint sont utilisés pour remplir le backlog d'ébauches de user stories et d’epics.

Lorsque vous créez votre backlog, il est essentiel de comprendre qu’il peut évoluer au fil du temps. La première ébauche n’a pas à être 100 % finalisée. Votre équipe affinera le backlog au fur et à mesure du recueil de nouvelles informations et de l’élaboration des user stories dans le temps. Votre équipe recueille des informations auprès du Product Owner, du ou des Business Analysts (BA), du Lead System Architect (LSA) et des testeurs. Pour la création du backlog, vous devez disposer d’un ensemble de points de vue différents pour déterminer ce qui est important, ce qu’il faut prioriser et quand livrer chaque user story.

Les backlogs évoluent constamment au fil du temps. Bien que le Product Owner soit responsable de la hiérarchisation du backlog, vous, en tant que Business Architect Pega, le rencontrez régulièrement pour le tenir au courant et le conseiller sur le statut actuel du projet.

En plus du bon de commande, assurez-vous que votre backlog comprend des user stories actualisées et qu’il est classé par ordre de priorité en fonction de la valeur métier de chacune de ces stories. De nouvelles user stories peuvent être priorisées par rapport à d’autres, et certaines peuvent être remplacées. Certaines user stories peuvent ne plus être nécessaires et être supprimées. La gestion et la priorisation du backlog est une tâche de fond qui se poursuit tout au long des phases du projet. 

Le Product Owner (PO) est responsable du backlog. Le PO crée le backlog, le maintient à jour, et priorise les user stories. Au début du projet, le Product Owner et l’équipe projet doivent convenir d’une approche de gestion du projet et des éléments de travail liés à l’application.

Le Product Owner dispose d’un large éventail de user stories à prioriser. Certaines stories sont très élaborées ; elles sont bien comprises et prêtes pour la phase de développement (build). D’autres en sont encore aux premiers stades du cycle de vie des user stories. Cette diversité implique que, lorsque le Product Owner priorise les stories dans le backlog, il doit tenir compte des objectifs à court terme pour la planification des sprints, mais aussi des objectifs à plus long terme pour la planification de l’élaboration.  

Vérifiez vos connaissances avec l’interaction suivante :