Menu

Artefacts Scrum: Backlog produit, Backlog Sprint et incréments de produit

  • Principal
  • Autre
  • Artefacts Scrum: Backlog produit, Backlog Sprint et incréments de produit

scrum artifacts product backlog

Essayez Notre Instrument Pour Éliminer Les Problèmes

Introduction aux artefacts Scrum:

Dans les articles précédents de cette série, on nous a présenté agile et les différentes méthodologies agiles . Nous avons également appris en quoi les différentes méthodologies sont différentes à leur manière.

Dans notre dernier tutoriel, nous sommes allés dans les détails de Scrum où nous avons discuté du Rôles Scrum comme Product Owner, Scrum Master et l'équipe Scrum et ont vu quelles étaient leurs responsabilités individuelles.

Dans ce tutoriel, nous continuons avec Scrum et approfondissons les détails des différents artefacts Scrum.

Artefacts Scrum

Ce que vous apprendrez:

Différents artefacts Scrum

3 types d'artefacts de mêlée comprennent:

  • Backlog produit
  • Backlog de sprint et
  • Incréments de produit

Nous allons maintenant voir ce que signifient ces termes et comment créer ces artefacts.

Types d

Backlog produit

Pour le dire en termes simples, un backlog de produit est une liste de tout ce qui est requis dans le produit. C'est le document final auquel se réfère l'équipe Scrum pour tout ce qui concerne le produit. Il s’agit d’une liste ordonnée d’articles appartenant au Product Owner (PO).

Le PO est responsable de la création, du maintien et de la hiérarchisation de cette liste. Les PO utilisent ce backlog de produit pour expliquer les principales exigences à respecter pendant le sprint aux équipes de mêlée.

Les éléments de cette liste peuvent ou non être dans un langage technique. Il peut même s'agir d'un langage profane, mais il doit contenir toutes les exigences du produit et les modifications qui l'accompagnent. De plus, avoir un backlog de produit ne signifie pas que l'équipe Scrum n'aura que cet artefact à suivre.

Ils peuvent créer leurs propres artefacts détaillés, mais ceux-ci ne contrediront ni ne remplaceront le backlog du produit. Ils seront plutôt alignés sur les exigences du backlog produit.

Voici un exemple de ce à quoi un backlog de produit typique peut ressembler:

HistoireEstimationPriorité
Je veux me connecter41
Je veux me déconnecterdeuxdeux
Je veux changer de mot de passe13
Je veux mettre à jour l'adresse34
Je souhaite ajouter un nouveau numéro de téléphone personnel15

Cela nous amène à la question, comment créer un bon backlog produit?

Un backlog de produit devrait idéalement suivre les règles ci-dessous:

(i) Il devrait être priorisé - Les articles du carnet de commandes du produit doivent être commandés selon leur priorité. Cette priorité peut être décidée par le PO et l'équipe Scrum ensemble. Les facteurs de priorisation peuvent être tout comme les avantages du point d'histoire, l'effort impliqué dans la création, la complexité, la priorité client, etc.

Cela aide l'équipe à comprendre ce qui doit être livré en premier.

(ii) Il doit être estimé - Les histoires doivent toujours être estimées selon la définition convenue, quelle qu'elle soit. Cela peut également être utilisé pour la hiérarchisation.

(iii) Il devrait être de haut niveau - Les histoires dans le backlog produit sont censées être de haut niveau et ne doivent pas entrer dans les détails. La création de user stories détaillées selon l'exigence appartient à l'équipe Scrum et non au PO.

(iv) Il doit être dynamique - Le backlog du produit n'est pas un document statique final. Il devrait être revisité au fur et à mesure que le PO reçoit les contributions de l'équipe Scrum et que les exigences du client deviennent de plus en plus claires. Ainsi, les exigences du document ne sont pas figées dès le début car il y a des ajouts / suppressions / modifications attendus au fur et à mesure de l'avancement du projet.

Le dernier point est le plus pertinent. Le but d'un backlog de produit est d'être une source d'exigences active. Il ne doit pas être créé au début, puis conservé dans un emplacement de stockage.

Au lieu de cela, il est destiné à être partagé encore et encore au fur et à mesure que les changements se produisent. De nouvelles exigences peuvent survenir au fur et à mesure que les progrès sont réalisés, ce qui peut également modifier la priorité des éléments du backlog. Il y aura des situations où une nouvelle exigence dépend d'un autre élément du backlog, de sorte que la priorité de l'élément devra peut-être être remaniée.

Ou il peut y avoir une user story critique qui devra peut-être être mise en œuvre en premier parce que le client veut voir cela avant les autres, même si elle n'est peut-être pas prioritaire selon les facteurs décidés par le PO et l'équipe Scrum.

Ainsi, le carnet de commandes du produit est une liste ordonnée des exigences commerciales détenues par le bon de commande et visitées à maintes reprises au fur et à mesure que le projet avance.

Backlog de sprint

Vous vous souviendrez peut-être que les équipes Scrum travaillent par courtes itérations de 2 à 4 semaines appelées sprint. Au cours de ces sprints, l'équipe Scrum identifie les éléments du backlog produit créé par le PO, qu'elle prévoit de livrer dans le cadre de la prochaine itération. Les éléments sur lesquels l'équipe Scrum choisit de travailler font partie du backlog de sprint.

Ainsi, ils décident des fonctionnalités qui seront présentes dans la prochaine itération du produit. L'équipe Scrum est celle qui décide de ce qui va entrer dans le backlog de sprint car ce sont eux qui vont y travailler.

Ce sont donc eux qui devraient estimer l'effort impliqué dans la mise en œuvre de ces histoires et décider de ce qu'ils peuvent fournir.

L'équipe choisit non seulement les éléments du backlog produit sur lesquels travailler, mais elle établit également une estimation du temps qu'il leur faudra pour développer cette fonctionnalité. Ils ajoutent également aux user stories de haut niveau en créant des tâches détaillées requises pour atteindre l'objectif de sprint.

j'ai besoin d'un nouveau fournisseur de messagerie

L'équipe Scrum peut également continuer à mettre à jour le backlog de sprint au fur et à mesure des besoins pendant le sprint, mais c'est uniquement l'équipe Scrum qui peut apporter des modifications au backlog de sprint.

Un Backlog Sprint typique ressemblera à celui ci-dessous.

Backlog de sprint

L'équipe peut idéalement mettre à jour cela une fois par jour et le scrum master peut utiliser ces informations pour créer un diagramme de burndown de sprint. Ce graphique de burndown aidera l'équipe à voir combien de travail reste encore pour le sprint et l'équipe peut planifier son travail en conséquence. Ils peuvent même ajouter ou supprimer des tâches si nécessaire.

Certaines bonnes pratiques lors de la création d'un backlog de sprint peuvent être:

# 1) Prendre des décisions de groupe - Ce ne devrait pas être le Scrum Master ou tout autre membre de l'équipe Scrum qui décide du backlog. Au contraire, c'est toute l'équipe qui décide ensemble des éléments à inclure dans le backlog de sprint et comment les planifier.

Chaque membre de cette équipe interfonctionnelle apporte ses propres compétences et il est essentiel que nous utilisions son expérience pour créer le meilleur backlog possible.

# 2) Ne pas attribuer de tâches - Comme cela a été répété à plusieurs reprises dans la littérature Agile, n'attribuez jamais de tâches aux membres de l'équipe. Une équipe Scrum est censée être autonome et doit savoir comment organiser son travail par elle-même.

Ainsi, au lieu d'attribuer du travail, nous devrions laisser l'équipe choisir elle-même le travail et décider entre elle de la manière dont elle souhaite procéder.

# 3) Définition de fait - Cela ne doit pas seulement être accepté par les parties prenantes, mais également être clairement visible pour l'équipe à tout moment chaque fois qu'elle doit prendre une décision concernant les objectifs du sprint. Cela leur servira de rappel de ce qui doit être fait exactement avant de pouvoir livrer un produit livrable en état de marche.

# 4) Continuez à mettre à jour le backlog - Il est impératif qu'au fur et à mesure que le sprint évolue, l'équipe acquière une meilleure compréhension et par conséquent, elle doit mettre à jour le backlog de sprint pour refléter également cette meilleure compréhension. Il ne doit à aucun moment devenir un document statique.

# 5) Ajoutez n'importe quelle tâche - La tâche ne doit pas seulement être liée au codage, mais elle peut être essentielle pour livrer un produit livrable. Par conséquent, mentionnez également ces tâches dans l'arriéré.

Incréments de produit

Cela nous amène au dernier artefact Scrum qui est les incréments de produit. Tel que défini par le guide Scrum, un incrément est la somme de tous les Éléments du backlog de produit terminé au cours d'un Sprint et la valeur des incréments de tous les Sprints précédents. Comme nous le savons bien maintenant, Scrum est un processus itératif.

Le résultat de chaque itération est cet incrément de produit et chaque incrément de produit aide l'équipe à faire un pas de plus vers la livraison du produit final.

Cela signifie que tout ce qui a été le résultat du sprint est un incrément. De toute évidence, pour que le résultat soit considéré comme un incrément, il doit d'abord répondre à la définition prédéfinie de terminé, c'est-à-dire que le résultat final doit être un produit utilisable qui peut être «expédié».

Il peut être vérifié, utilisé et testé pour s'assurer qu'il est effectivement «fait» selon la définition et si le Product Owner le souhaite, il peut également être mis en ligne.

La chose la plus importante pour fournir cet incrément de produit est d'avoir une compréhension commune de la «définition de terminé» qui est comprise par tous.

L'équipe Scrum ne devrait jamais avoir le moindre doute quant à savoir si ce qu'elle fait sera accepté ou non. En cas de doute, la définition de fait doit être suffisamment complète pour les guider sur la façon de procéder. Sur la base de cette définition uniquement, l'équipe Scrum décide du nombre d'éléments du backlog produit à sélectionner pour le sprint.

C'est le minimum que l'on attend du sprint.

Conclusion

À partir de ce didacticiel, nous avons compris quels sont les 3 artefacts Scrum, qui les possède ainsi que certaines des meilleures pratiques qui nous aideraient à créer des artefacts de meilleure qualité. Dans nos prochains tutoriels de cette série, nous discuterons des événements Scrum et verrons comment exécuter ces événements.

Dans notre prochain tutoriel sur 'Scrum Événements , 'Nous discuterons de chacun des événements Scrum en détail!

Tutoriel PREV | Tutoriel SUIVANT

lecture recommandée

^