Groupe d’utilisateurs impliqués dans le travail et l’achèvement du développement d’un produit Agile. Dans Développement agile 2.0, cette équipe est appelée en tant que groupe d’affectation.

Dans un groupe d’affectation, un utilisateur est désigné comme Scrum Master, qui est chargé de s’assurer que toutes les activités Scrum sont correctement exécutées pour une mise en production. Pour plus d'informations, consultez Groupes d’affectation dans Développement agile 2.0.

Définition de haut niveau d’un besoin qui apporte de la valeur à l’entreprise, comme une nouvelle fonctionnalité ou une amélioration significative. Les épopées sont décomposées en stories Agile et peuvent être traitées par une ou plusieurs équipes.

Des œuvres courtes et gérables liées à une épopée. Les stories capturent le qui, le quoi et le pourquoi d’un besoin 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 requis pour y mettre en œuvre le travail.

Tâches distinctes requises pour terminer une story. Une tâche peut nécessiter de 4 à 12 heures.

Liste des travaux qui doivent être mis en œuvre dans le cadre de l’atteinte de résultats précis. 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 produits.

Le backlog est considéré comme la source unique de travail pour un produit ou une équipe. Tout ce qui n’est pas inclus dans le backlog ne sera pas prioritaire 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 filtrage pertinents. Dans Développement agile 2.0, les propriétaires de produits peuvent 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 en tout temps.

Périodes courtes et fixes, au cours desquelles les membres de l’équipe sélectionnent et terminent un nombre défini de stories. Ces cycles courts et limités dans le temps offrent aux équipes la flexibilité nécessaire pour s’adapter à l’évolution des priorités.

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 des travaux d’un sprint. Les propriétaires de produit et leurs équipes de développement profitent de l’activité de planification du sprint pour examiner leur backlog et décider des stories à prendre en compte pour un sprint.

Domaine d’intérêt avec une valeur commerciale associée. Un thème est lié à un ou plusieurs objectifs de l’entreprise. Les thèmes vous aident à hiérarchiser votre travail à un niveau élevé et peuvent être associés à plusieurs épopées.

Entité permettant d’organiser les thèmes, les épopées et les stories de fonctionnalités similaires dans un contexte unique. Un produit représente un article ou une fonctionnalité qui doit être développé et mis sur le marché.

Une mise en production présente une date de début et une date de fin au cours desquelles plusieurs itérations de développement sont réalisées. Les mises en production sont créées par un propriétaire de produit et contiennent des user stories, parfois issues de plusieurs produits, et peuvent également impliquer plusieurs équipes. Les stories associées à une mise en production forment 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 constatés lors du développement d’une nouvelle fonctionnalité, ou comme commentaires pour les fonctionnalités existantes. Les propriétaires de produits examinent ensuite ces défauts et décident de créer des stories pour eux, qui sont affectées aux groupes d’affectation appropriés.

À l’aide de , Développement agile — Backlog unifié vous pouvez configurer un tableau de triage afin de 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 Développement agile — Backlog unifié.

Les demandes d’amélioration permettent de consigner les améliorations apportées aux fonctionnalités d’un produit. Ces demandes peuvent découler de besoins internes ou de commentaires des clients. Les propriétaires de produits examinent ces demandes enregistrées et décident de créer des stories en fonction de leur priorité. Ces stories sont ensuite affectées aux groupes d’affectation appropriés pour le développement.

À l’aide de , Développement agile — Backlog unifié vous pouvez configurer un tableau de triage afin de 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 Développement agile — Backlog unifié.

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 dans les articles les mieux classés. Le groupe décide quelles tâches Scrum sont nécessaires pour chaque story. Le propriétaire du produit 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 de la veille, du travail planifié pour le jour et des éventuels obstacles. Le point quotidien permet aux membres du groupe de se concentrer sur l’achèvement des stories pour le sprint en cours et informe le Scrum Master des éventuels obstacles.

À la fin du sprint, toutes ses stories doivent être terminées. Toute story incomplète est renvoyée dans le backlog ou dans un futur sprint.

Des réunions de revue de sprint ont lieu à la fin de chaque sprint. Au cours de ces réunions, le groupe d’affectation passe en revue le travail qu’il a effectué et présente les nouvelles fonctionnalités à son propriétaire de produit.

Une réunion rétrospective est organisée à la fin de chaque sprint, afin de faciliter la discussion entre les membres du groupe sur ce qui s’est bien passé et ce qui n’a pas fonctionné. L’objectif d’une rétrospective de sprint est de discuter des moyens d’améliorer l’exécution des futurs sprints.

Pour en savoir plus sur la manière Développement agile 2.0 dont vous pouvez gérer vos efforts de développement de produits, reportez-vous à la rubrique Développement agile Flux de processus.