Groupe d'utilisateurs impliqués dans la création et la réalisation du développement d'un produit Agile. Dans Agile Development 2.0, cette équipe est appelée groupe d'affectation.

Dans un groupe d'affectation, un utilisateur est appelé Scrum Master ; il est chargé de s'assurer que toutes les activités Scrum sont correctement effectuées pour une mise en production. Pour plus d'informations, consultez Groupes d’affectation dans Agile Development 2.0.

Définition de haut niveau d'une exigence qui fournit de la valeur pour l'entreprise, par exemple une nouvelle fonctionnalité ou une amélioration significative. Les épopées sont décomposées en stories Agile et peuvent être utilisées par une seule ou plusieurs équipes.

Brefs éléments de travail gérables associés à une épopée. Les stories définissent les exigences et leurs fonctions, ainsi que les personnes qui les utilisent, de manière simple et concise. À l'aide de la description et des critères mentionnés dans les stories, les équipes peuvent estimer avec précision l'effort nécessaire pour implémenter le travail.

Différentes tâches requises pour terminer une story. Une tâche peut nécessiter entre 4 et 12 heures.

Liste des travaux qui doivent être mis en œuvre en vue d'atteindre des résultats spécifiques. Le backlog contient des travaux liés aux nouvelles fonctionnalités, aux améliorations apportées aux fonctionnalités existantes et à d'autres activités de développement de produit.

Le backlog est considéré comme l'unique source de travail pour un produit ou une équipe. Tout ce qui n'est pas inclus dans le backlog n'est pas classé par ordre de priorité pour le développement.

Les propriétaires de produits définissent un pipeline de travail personnalisé appelé backlog personnel en appliquant des critères de filtre pertinents. Dans Agile Development 2.0, le propriétaire de produit peut définir autant de backlogs personnalisés que nécessaire. Les critères utilisés pour créer le backlog personnalisé sont flexibles et peuvent être modifiés à tout moment.

Périodes courtes et fixes dans lesquelles les membres de l'équipe sélectionnent et terminent un nombre défini de stories. Ces cycles courts et chronométrés offrent aux équipes la flexibilité de s'adapter aux priorités changeantes.

La cadence de récurrence d'un sprint est décidée par les équipes de développement et les propriétaires de produits. Par exemple, un sprint de 10 jours ou un sprint d'une semaine.

Champ d'application du travail pour un sprint. Les propriétaires de produits et leurs équipes de développement utilisent l'activité de planification des sprints pour examiner leurs backlogs et décider des stories à récupérer pour un sprint.

Domaine d'intérêt avec une valeur commerciale associée. Un thème est lié à un ou plusieurs des objectifs de l'entreprise. Les thèmes vous aident à classer votre travail par ordre de priorité à un niveau élevé ; ils peuvent être associés à plusieurs épopées.

Entité chargée d'organiser les thèmes, les épopées et les stories à fonctionnalité similaire en un seul contexte. Un produit représente un élément ou une fonctionnalité à développer et publier sur le marché.

Une mise en production possède une date de début et une date de fin, entre lesquelles sont effectuées plusieurs itérations de développement. Les mises en production sont créées par un propriétaire de produit et contiennent des stories d'utilisateurs, parfois issues de plusieurs produits, et peuvent également impliquer plusieurs équipes. Les stories associées à un formulaire de mise en production constituent son backlog de mise en production.

Après avoir créé des stories et des tâches Scrum pour vos produits, vous pouvez créer un backlog personnalisé contenant les stories d'un ou de plusieurs de ces produits.

Les défauts peuvent être utilisés pour signaler et suivre la résolution des problèmes remarqués lors du développement d’une nouvelle fonctionnalité, ou comme commentaire pour les fonctionnalités existantes. Les propriétaires de produits examinent ensuite ces défauts et décident de créer les stories correspondantes, qui sont affectées aux groupes d'affectation appropriés.

À l’aide de , Agile Development — Unified Backlogvous pouvez configurer un tableau de triage pour gérer un backlog centralisé pour les enregistrements de différents types de tâches, tels que les défauts, les stories et les améliorations. Pour plus d'informations, consultez Agile Development — Unified Backlog.

Vous pouvez utiliser les demandes d'amélioration pour consigner les améliorations de fonctionnalités d'un produit. Ces demandes peuvent résulter de besoins internes ou de commentaires des clients. Les propriétaires de produits examinent ces demandes consignées et décident de créer les stories correspondantes en fonction de leur priorité. Ces stories sont ensuite affectées aux groupes d'affectation appropriés pour le développement.

À l’aide de , Agile Development — Unified Backlogvous pouvez configurer un tableau de triage pour gérer un backlog centralisé pour les enregistrements de différents types de tâches, tels que les défauts, les stories et les améliorations. Pour plus d'informations, consultez Agile Development — Unified Backlog.

Les membres du groupe d'affectation se réunissent pour décider des stories qu'ils peuvent s'engager à livrer dans le sprint. En règle générale, ils s'engagent d'abord sur les stories ayant le plus haut niveau de priorité. Le groupe décide des tâches Scrum qui sont nécessaires pour chaque story. Le product owner doit être présent pour répondre à toutes les questions.

Les membres du groupe d'affectation se réunissent pour discuter de l'avancement de leur travail du jour précédent, du travail planifié pour le jour actuel et de tous les bloqueurs. La réunion quotidienne permet aux membres du groupe de rester concentrés sur les stories à terminer pour le sprint en cours et informe le Scrum Master des éventuels bloqueurs.

À la fin du sprint, toutes ses stories doivent être terminées. Les stories incomplètes doivent être déplacées vers le backlog ou vers un sprint à venir.

Les réunions d'examen du sprint ont lieu à la fin de chaque sprint. Au cours de ces réunions, le groupe d'affectation examine le travail qu'il a effectué et effectue une démonstration des fonctionnalités nouvellement développées pour son propriétaire de produit.

Une réunion rétrospective est organisée à la fin de chaque sprint pour que les membres du groupe puissent analyser les réussites et les erreurs. L'objectif d'une rétrospective de sprint est de discuter des moyens d'améliorer l'exécution des sprints futurs.

Pour en savoir plus sur comment Agile Development 2.0 peut vous aider à gérer vos efforts de développement de produits, voir Flux de processus Agile Development.