Terminologie Agile Azure DevOps : Epic, Feature, User Story, Task
À la fin de ce tutoriel, vous saurez nommer et hiérarchiser les work items Agile dans Azure Boards : Epic, Feature, User Story, Task, puis Issue, Bug et Test Case — avec un exemple concret (school Management) et les états New → Active → Resolved → Closed.
Niveau : Débutant · Temps estimé : 35–50 min · Versions testées : Azure DevOps Services (portail 2026), process Agile · Dernière vérification : 2026-09-12
Slug :
agile-terminology· Série : Azure DevOps (menu) · WP #1026 · Focus SEO :terminologie agile azure devops
Prérequis
- Organisation et projet lab Azure DevOps (process Agile) — Azure Projects, Project Processes
- Panorama Boards : Azure Boards ; labs : Boards Lab, Sprint Lab
- Contexte SDLC / Agile : SDLC & DevOps Introduction, SDLC Methodologies
- Optionnel P4 : work items, backlogs et sprints
- Navigateur récent ; 0 € (Boards Free tier) — aucune ressource Azure facturable
Coût estimé : gratuit. Gardez le vocabulaire sous la main avant de créer des dizaines de work items « au feeling ».
Ce que nous allons construire
Process Agile (Azure Boards)
├── (Option) Initiative → découpe en Epics
├── Epic → objectif org, multi-équipes / multi-sprints
│ └── Feature → unité de release / release notes
│ └── User Story → unité de travail de l’équipe
│ └── Task → travail technique concret
├── Bug / Issue → défauts & blocages
└── Test Case → vérifications
États typiques : New → Active → Resolved → Closed
Exemple : school Management (Attendance, Library, Finance…)
(Schéma local Excalidraw / draw.io, alt : « Hiérarchie Agile Azure DevOps : Epic, Feature, User Story, Task, Bug, Issue, Test Case ».)
Fond EN conservé et enrichi : les définitions Epic / Feature / Stories / Tasks, l’exemple school Management, les listes d’Issues / Bugs / Test Cases et les états New / Active / Resolved / Closed restent le fil — densifiés en FR pour Azure Boards 2026.
Étape 1 — Pourquoi la terminologie Agile compte
Sans vocabulaire partagé, un backlog devient illisible : tout le monde crée des « tasks » géantes, les release notes mélangent bugs et features, et le board Kanban ne reflète plus la valeur livrée. Azure DevOps process Agile impose une hiérarchie claire pour que produit, dev et QA parlent la même langue.
Cette page (Lesson historique du parcours Azure DevOps) fixe les termes avant les labs clics (Boards Lab, Sprint Lab). Objectif : lire un board, découper un Epic, et savoir si un item est une Story, une Task ou un Bug — en 30 minutes chrono.
En 2026, les libellés UI restent en anglais sur Azure DevOps Services. On écrit le tutoriel en FR ; on conserve Epic, Feature, User Story, Task, Bug, Issue, Test Case, Sprint, Backlog, Board.
Étape 2 — Epics (fond conservé)
Epics declare initiatives important to the organization’s success. Epics may take several teams and several sprints to accomplish, but they are not without an end. Epics have a clearly defined goal. Once attained the Epic is closed. The number of Epics in progress should be manageable, to keep your organization focused. Epics are broken down into Features. Many organizations introduce a level above Epics called Initiatives ; Initiatives break down into Epics.
En pratique Azure Boards :
- Créez un work item Epic (Boards → Work items → New Work Item → Epic).
- Titre orienté outcome (« Plateforme inscription étudiants »), pas une liste technique.
- Limitez les Epics Active (WIP) : 2–5 par équipe produit est déjà beaucoup.
- Liez des Features enfants (Add link → Child) plutôt que d’empiler 40 Stories orphelines.
Un Epic sans date de fin mentale devient un tiroir fourre-tout. Quand le goal est atteint → Closed.
Étape 3 — Features (fond conservé)
Features define new functionality required to realize an Epic’s goal. Features are the release unit, that is, they represent what is released to the customer. Your published release notes can be built based on the list of Features recently completed. Features can take multiple sprints to complete but should be sized to ensure a consistent flow of value to the customer. Features are broken down into stories.
Traduction opérationnelle :
| Question | Réponse Feature |
|---|---|
| Qu’est-ce qui part en prod / chez le client ? | La Feature |
| Quoi mettre dans les release notes ? | Titres de Features Done |
| Trop grosse ? | Découper en 2 Features, pas en 1 Story mammouth |
Dans Azure Boards, une Feature porte souvent Area Path + Iteration Path de release. Les User Stories enfants doivent pouvoir être planifiées sprint par sprint.
Étape 4 — User Stories (fond conservé)
Stories define incremental value the team must deliver to create a Feature. The team breaks the Feature down into incremental pieces. A single completed story may not provide meaningful value to the customer. However, a completed story represents production-quality software. Stories are the team’s work unit. The team defines the stories required to complete a Feature. Stories optionally breakdown into Tasks.
Format classique (EN, conservé en lab) :
As a <role>, I want <capability>, so that <benefit>.
Bonnes pratiques :
- INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
- Critères d’acceptation en puces (Given / When / Then ou checklist)
- Une Story Done = déployable / mergeable selon la Definition of Done de l’équipe — pas un WIP technique caché
- Estimation relative (story points) ou capacité sprint — pas besoin de micro-heures ici (c’est le rôle des Tasks)
Étape 5 — Tasks (fond conservé)
Tasks define the work required to complete a work item.
Sous une User Story : « créer l’endpoint », « écrire le test unitaire », « mettre à jour le README lab ». Les Tasks portent souvent Remaining Work (heures) et un Assigned To. Elles aident le daily standup ; elles ne remplacent pas la Story dans le backlog produit.
Règle simple : le Product Owner priorise Stories / Features ; l’équipe découpe en Tasks pendant le planning ou en cours de sprint.
Étape 6 — Exemple school Management (listes d’origine conservées)
If you design a school Management project, states can be New, Active, Resolved, Closed.
Epic (exemples d’origine)
- Attendance Register
- Student Registration
- Library Management
- Finance Management
Features (exemples d’origine)
- Time Table
- Books Catalog
- Student Signup
- Notice board
- Fee Structure
User Stories (exemples d’origine)
- Define the login to portal process
- When a user wants to see the results on the web portal
- As an admin, modify student’s detail
- As a student can see the marks of the academic year.
Tasks (exemples d’origine)
- As a user, I want to view a public landing page with static information.
- As a user, I want to list all the students class-wise.
- As a user, I want to see the results of all the students subject-wise
Astuce pédagogique : dans un vrai backlog Agile, les trois lignes « Tasks » ci-dessus ressemblent plutôt à des User Stories (format As a…). En lab, gardez-les comme dans l’historique de la page, puis renommez / reclassez si vous formalisez le projet DemoProj.
Issues (exemples d’origine)
- The user is not able to log in
- Networking is not established between Web servers and DB servers
- Waiting for test results
Bugs (exemples d’origine)
- Application is throwing an exception on the login page
- Reports are not showing accurate results.
Test Cases (exemples d’origine)
- Verify whether existing users are able to login with their credentials or not.
- Verify school logo has appeared on all the web pages.
Cartographie rapide school → hiérarchie :
- Epic Student Registration → Feature Student Signup → Stories login / admin modify detail
- Epic Library Management → Feature Books Catalog
- Epic Finance Management → Feature Fee Structure
- Epic Attendance Register → Feature Time Table + Notice board selon le scope
Étape 7 — États New, Active, Resolved, Closed
Sur process Agile, le cycle de vie typique d’une User Story / Bug est :
| État | Sens courant |
|---|---|
| New | Créé, pas encore démarré |
| Active | En cours (dev, review, test) |
| Resolved | Travail « fini » côté implémentation, validation restante |
| Closed | Accepté / terminé selon DoD |
Le board Kanban mappe ces états en colonnes. Ne créez pas 12 colonnes custom avant d’avoir un flux stable New → Active → Resolved → Closed. Pour le lab : Boards Lab (New → Active) puis Sprint Lab (capacity + dates).
az devops configure --defaults organization=https://dev.azure.com/VOTRE_ORG project=DemoProj
az boards work-item show --id <ID> -o table
(Remplacez l’org ; aucun PAT en clair dans Git.)
Étape 8 — Issues, Bugs et Test Cases
Issue : souvent un blocage / risque / demande transversale (réseau down, attente résultats de test). Utile pour rendre visible un impediment sans le déguiser en Feature.
Bug : défaut logiciel reproductible (exception login, rapports faux). Liez le Bug à la Story / Feature concernée ; priorisez avec le même backlog (ou un backlog Bugs selon la convention d’équipe).
Test Case : étape de vérification (login credentials, logo sur toutes les pages). Dans Azure Test Plans / Boards selon la config org — ici on retient l’intention QA de l’exemple school.
Ne confondez pas : un « user cannot log in » peut être Issue (infra) ou Bug (exception applicative). Choisissez selon la cause racine connue.
Étape 9 — Bonnes pratiques sizing et Definition of Done
- WIP Epics : peu d’Epics Active ; beaucoup de Features/Stories Done vaut mieux qu’un Epic éternel.
- Feature = release note : si vous ne pouvez pas l’expliquer au métier en une phrase, découpez.
- Story = production-quality : pas de « Story technique » sans valeur ni test.
- Task = heures : pour le daily, pas pour remplacer le backlog produit.
- DoD écrite : code review, tests, pas de secret en clair, doc lab minimale.
- Alignez le process template : Agile vs Scrum vs Basic — voir Project Processes.
Erreurs fréquentes
- Tout mettre en Task : le board devient un todo technique, les release notes vides.
- Epic sans Features : 80 Stories enfants, priorisation impossible.
- Feature = un sprint exact : trop rigide ; visez un flux de valeur, pas un calendrier figé.
- Bug jamais lié : dette invisible, mêmes régressions chaque release.
- Ignorer les états : laisser 30 items Active sans Resolved/Closed fausse la vélocité.
Quiz (3 questions)
Q1. Quelle entité est typiquement l’unité de release notes côté métier ?
Réponse : la Feature.
Q2. Une User Story terminée doit représenter quoi, même si elle n’apporte pas toute la valeur client seule ?
Réponse : du logiciel production-quality (qualité prod), pas un prototype jetable.
Q3. Dans l’exemple school, « Application is throwing an exception on the login page » est un…
Réponse : Bug.
Maillage
- Précédent / panorama : Azure Boards, Project Processes
- Labs suivants : Azure Boards Lab, Azure Sprint Lab
- Identité & accès : Azure Active Directory, Add AD Users
- SDLC : SDLC & DevOps Introduction, SDLC Methodologies
- P4 approfondi : Azure Boards work items
Retour parcours Azure DevOps — hub de la série et leçons sœurs.
