Azure Sprint Lab : Tasks, iterations et Taskboard (DemoProj)

À la fin de ce lab, vous aurez créé les Tasks Application SignIn Task1 et Application SignIn Task2, les aurez liées en Child à la user story SignInModule, assigné story et Tasks à iteration1, vérifié le Taskboard sous Boards → Sprints, répété le parcours pour SignUpModule sur iteration2, puis créé un nouveau Sprint daté avec de nouvelles Tasks — le fil historique de cette page, modernisé pour Azure DevOps Services 2026.

Niveau : Débutant · Temps estimé : 40–55 min · Versions testées : Azure DevOps Services (portail 2026), process Agile, Boards / Sprints · Dernière vérification : 2026-09-12

Slug : azure-sprint-lab · Série : Azure DevOps (Lesson 15 / 31) · WP #1036 · Prérequis logique : Boards Lab

Prérequis

• Projet DemoProj (Private, process Agile) avec les user stories SignInModule et SignUpModule déjà créées, assignées et passées en Active — voir Azure Boards Lab (Lesson 14)
• Organisation Azure DevOps lab et droits Contributors (ou plus) sur DemoProj pour créer des work items et modifier les iterations
• Avoir parcouru le panorama Azure Boards ; optionnel P4 : work items, backlogs et sprints
• Navigateur récent ; budget : 0 € (Boards Free tier) — aucune ressource Azure facturable

Coût estimé : gratuit. Ce lab ne provisionne aucune VM ni App Service : uniquement des work items et des chemins d’itération.

Checklist Lesson 15 : (1) DemoProj ouvert, (2) SignInModule + SignUpModule visibles en Active, (3) accès Boards → Sprints, (4) objectif clair : Tasks enfants + iteration1/2 + Taskboard + nouveau sprint daté.

Ce que nous allons construire

DemoProj (Agile)
  ├── Iterations
  │     ├── iteration1  ← SignInModule + Application SignIn Task1/2
  │     ├── iteration2  ← SignUpModule + Tasks SignUp
  │     └── Nouveau Sprint (Start Date / End Date) ← Tasks du sprint frais
  ├── User Story SignInModule
  │     ├── Child : Application SignIn Task1
  │     └── Child : Application SignIn Task2
  ├── User Story SignUpModule
  │     └── Child Tasks (même schéma, iteration2)
  └── Boards → Sprints → Taskboard (stories + Tasks du sprint sélectionné)

(Schéma pédagogique — alt : « Azure Sprint Lab : Tasks enfants, iterations et Taskboard sur DemoProj ».)

Fond EN conservé et enrichi : le parcours d’origine (créer deux Tasks SignIn, les lier en Child à SignInModule, pousser story + Tasks dans iteration1, contrôler le Taskboard, répéter pour SignUpModule / iteration2, puis créer un sprint daté et y ajouter des Tasks) reste le fil — vocabulaire portail 2026, pièges courants et validation bout-en-bout ajoutés.

Pourquoi les sprints et les Tasks comptent

Dans Azure Boards, une User Story décrit le besoin ; une Task découpe le travail technique (heures, assignee, état). L’Iteration Path (souvent appelé sprint) ancre ce travail dans une fenêtre de temps. Sans Tasks liées, le Taskboard reste plat ; sans iteration, les items restent sur le backlog produit et n’apparaissent pas dans Boards → Sprints.

Ce lab enchaîne hiérarchie (Parent/Child), planification (iteration1/2 + nouveau sprint) et visualisation (Taskboard) — pont entre Lesson 14 et la suite Repos/Pipelines.

Étape 1 — Créer Application SignIn Task1 et Application SignIn Task2

Ouvrez le projet DemoProj → Boards → Work items (ou ouvrez directement la story SignInModule).

1. New Work Item → type Task.
2. Title exact du lab : Application SignIn Task1 → Save.
3. Répétez pour Application SignIn Task2.
4. Optionnel mais recommandé : renseignez Remaining Work (ex. 2 et 2 heures) et Assigned To (vous-même ou un compte lab).

Vous pouvez aussi créer les Tasks depuis la story : ouvrir SignInModule → section Related Work / liens → Add link → New item → Child Task. Les deux chemins sont valides ; le lab historique sépare création puis liaison (étapes 1–2).

Nommage : gardez les titres historiques (Application SignIn Task1 / Task2) pour rester aligné avec la série et les captures de formation. Évitez les titres vagues du type « todo 1 ».

Pièges création : type Bug au lieu de Task → mauvais workflow sur le Taskboard ; Remaining Work laissé vide → capacité sprint peu lisible ; secrets (PAT, mots de passe) collés dans Description → à proscrire absolument.

Étape 2 — Lier les Tasks en Child à SignInModule

1. Ouvrez la user story SignInModule.
2. Dans Related Work, cliquez Add link.
3. Link type : Child (ou « Parent » depuis la Task — l’effet est le même : story parente, Tasks enfants).
4. Ajoutez Application SignIn Task1 puis Application SignIn Task2 (ou sélectionnez les deux si le sélecteur le permet).
5. OK / Save sur la story.

Vérifiez la hiérarchie : sous SignInModule, les deux Tasks apparaissent comme enfants. Dans Backlogs, basculez éventuellement le niveau pour voir Stories avec Tasks expansibles.

Pourquoi Child ? Le Taskboard et les vues de sprint agrègent le travail sous la story. Un lien « Related » / « Successor » ne remplace pas la relation Parent/Child pour le planning agile standard.

Étape 3 — Assigner iteration1 à SignInModule et aux deux Tasks

1. Ouvrez SignInModule → champ Iteration (Iteration Path).
2. Sélectionnez iteration1 (chemin typique : DemoProj\iteration1 ou l’équivalent sous votre racine d’iterations).
3. Si iteration1 n’existe pas encore : Project settings → Project configuration → Iterations → New → nommez iteration1 → Save, puis réassignez.
4. Ouvrez Application SignIn Task1 → Iteration = iteration1 → Save.
5. Idem pour Application SignIn Task2.

Le lab d’origine insiste : story et Tasks doivent partager la même iteration. Une story en iteration1 avec des Tasks « @ Current » / backlog produit disparaîtra partiellement du Taskboard du sprint.

Team Iterations : Project settings → Teams → Iterations : cochez iteration1 (sinon elle n’apparaît pas dans Boards → Sprints).

Étape 4 — Vérifier Boards → Sprints (Taskboard SignIn)

1. Allez dans Boards → Sprints.
2. Sélectionnez iteration1 dans le sélecteur de sprint (haut de page).
3. Ouvrez la vue Taskboard (parfois nommée « Board » au niveau sprint, colonnes orientées Tasks).
4. Vous devez voir la user story SignInModule et ses Tasks Application SignIn Task1 / Task2.

Faites glisser une Task de To Do / New vers In Progress / Active pour valider que le workflow répond. Remettez l’état si vous voulez garder le lab « propre » pour une démo.

Si le Taskboard est vide : (a) mauvaise iteration sélectionnée, (b) Tasks sans Parent, (c) filtres « Mine » / Area Path, (d) iteration non assignée à la team. Corrigez dans cet ordre avant de refaire les étapes 2–3.

Étape 5 — Répéter pour SignUpModule sur iteration2

Rejouez le même scénario pour la seconde story du Boards Lab :

1. Créez deux Tasks, par ex. Application SignUp Task1 et Application SignUp Task2 (équivalent SignUp du lab d’origine « Repeat Step 1 to Step 4 »).
2. Liez-les en Child à SignUpModule.
3. Créez ou sélectionnez iteration2 ; assignez SignUpModule + les deux Tasks à iteration2.
4. Boards → Sprints → sélectionnez iteration2 → confirmez le Taskboard (story + Tasks).

Séparer SignIn sur iteration1 et SignUp sur iteration2 illustre clairement le changement de sprint dans le sélecteur : chaque Taskboard ne montre que le travail de l’iteration courante. C’est exactement le geste pédagogique du lab historique.

Étape 6 — Créer un nouveau Sprint daté et y ajouter des Tasks

1. Project settings → Project configuration → Iterations.
2. New child sous la racine DemoProj (ou sous un nœud Release si vous en avez un).
3. Nommez clairement, ex. Sprint 3 ou Nouveau Sprint Lab.
4. Renseignez Start Date et End Date (ex. aujourd’hui → +14 jours) — le lab d’origine demande explicitement ces dates.
5. Save.
6. Assignez ce sprint à la team (Teams → Iterations).
7. Créez quelques Tasks (ou une mini-story + Tasks), liez-les correctement, placez-les dans ce nouveau sprint.
8. Boards → Sprints → sélectionnez le nouveau sprint → vérifiez le Taskboard.

Les dates alimentent le burndown et la capacité : sans Start/End, Azure DevOps accepte l’iteration mais les graphiques de sprint restent peu parlants. Pour un lab formation, deux semaines est une durée simple à expliquer.

Étape 7 — Capacité, Remaining Work et bonnes pratiques

Bonnes pratiques lab (capacité sprint via Boards → Sprints → Capacity si disponible) :

• Une Task = un résultat technique en moins d’une journée idéalement ; découpez si « Application SignIn Task1 » grossit trop.
• Ne mélangez pas iteration1 et iteration2 sur la même story sans raison : le Taskboard devient confus pour les stagiaires.
• Titres stables (Application SignIn Task1) aident les formateurs à corriger rapidement.
• Aucun secret dans Description, Attachments ou commentaires de work item.

Validation bout-en-bout

1. Application SignIn Task1 et Application SignIn Task2 existent (type Task).
2. Les deux sont Child de SignInModule.
3. SignInModule + Tasks → iteration1 ; visibles sur Taskboard de iteration1.
4. Parcours équivalent pour SignUpModule → iteration2.
5. Un nouveau Sprint avec Start Date / End Date existe ; au moins une Task (ou story+Tasks) y est planifiée et visible sur son Taskboard.
6. Aucun secret dans les work items.

Mini-checklist Lesson 15 : Tasks SignIn liées · iteration1 OK · Taskboard OK · SignUp / iteration2 OK · sprint daté créé · prêt pour la suite Repos / Pipelines.

Nettoyage

• Gardez DemoProj, les stories et les Tasks : utiles pour enchaîner sur Repos (lier commits aux WI) et Pipelines.
• Vous pouvez fermer (Closed) les Tasks de démo après validation, sans supprimer le projet.
• Si vous devez tout détruire : Project settings → Overview → Delete — uniquement sur un projet jetable.
• Révoquez tout PAT créé pour des essais CLI (az boards).

Erreurs fréquentes

Quiz (3 questions)

1. Quelle relation doit relier Application SignIn Task1 à SignInModule ?
– A. Related uniquement
– B. Child (story parente, Task enfant)
– C. Duplicate

2. Après l’étape 3 du lab, où doivent se trouver story SignIn et ses Tasks ?
– A. Uniquement sur le backlog produit, sans iteration
– B. Sur iteration1 (story et Tasks)
– C. Sur iteration2 uniquement

3. Que demande l’étape « Create a new Sprint » du lab d’origine ?
– A. Supprimer iteration1 et iteration2
– B. Créer un sprint avec Start Date et End Date, puis y ajouter des Tasks (repeat)
– C. Publier le projet en Public

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

• Doc officielle : About Sprints, Taskboard, Link work items
• Suite / contexte : Azure Boards Lab · Azure Boards · P4 work items / sprints
• Vocabulaire : Agile terminology · Azure Project Processes

Maillage série Azure DevOps

Retour parcours Azure DevOps — hub de la série et leçons sœurs.