Microsoft AZ-400: Agile Planning en Werkbeheer — Studiegids

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Onderdeel van de Microsoft DevOps Engineer Expert AZ-400 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Agile planning en work management in Azure DevOps draaien om een helder datamodel, gedisciplineerde flow- en iteratiepraktijken, en zichtbaarheid over teams heen. Azure Boards biedt een robuuste hiërarchie van work item types en flexibele configuraties per team, terwijl GitHub Projects moderne, door automatisering gedreven planning biedt die nauw is geïntegreerd met Issues en Pull Requests. Effectieve adoptie hangt af van rigoureuze definities (Definition of Done, acceptatiecriteria), consistente schattingen (story points en relatieve inschatting), en bruikbare inzichten (queries, delivery plans en metrics, inclusief DORA). De volgende secties beschrijven hoe je deze praktijken op grote schaal kunt ontwerpen, implementeren en beheren.

Azure Boards-datamodel, proces-templates en teamconfiguratie

Work item types en de hiërarchie vormen de ruggengraat van de planning. In het standaard Agile-proces is de portfoliohiërarchie Epic > Feature > User Story, met Task en Bug als items op uitvoeringsniveau. Child-links leggen de decompositie vast (User Story → Task) en Bugs kunnen op hetzelfde backlog-niveau als User Stories worden beheerd of onafhankelijk worden getrieerd, afhankelijk van het teambeleid. Link types zijn essentieel:

Parent/Child: legt de decompositiehiërarchie vast en stuurt de rollup van voortgang en inspanning.
Predecessor/Successor: drukt planning- en afhankelijkheidsrelaties tussen work items uit; deze verschijnen in Delivery Plans als afhankelijkheidslijnen.
Related/Duplicate/Blocked by: modelleert niet-hiërarchische relaties en impediments.
Artifact-links: verbindt work items met code (commits, branches, PRs), builds en releases, wat end-to-end traceerbaarheid mogelijk maakt.

Azure DevOps process-templates definiëren statussen, velden en de naamgeving van WIT’s:

Agile: Het item op requirement-niveau is User Story; snel bewegende teams kiezen hier vaak voor.
Scrum: Het item op requirement-niveau is Product Backlog Item (PBI); sprints en Scrum-artefacten zijn ‘first-class’ en Bugs kunnen worden geconfigureerd om zich als PBI’s te gedragen.
CMMI: Het item op requirement-niveau is Requirement en het bevat WIT’s voor Change Request, Risk en Review—kies dit als je risico’s en formele reviews moet bijhouden.
Custom (Inherited) processen: In Azure DevOps Services kun je een systeemproces uitbreiden via Inheritance om aangepaste WIT’s, statussen, regels en velden toe te voegen met behoud van servicecompatibiliteit. Gebruik categorieën om een aangepaste WIT op het juiste backlog-niveau te plaatsen. Vermijd overmatige aanpassingen die de rapportage bemoeilijken; standaardiseer velden zoals Story Points en Remaining Work.

Teams zijn lichtgewicht partities die geconfigureerd worden via:

Area paths: bakenen eigenaarschap en backlog-filtering af; teams selecteren een of meer area paths (en kunnen optioneel onderliggende area’s opnemen) om ‘hun’ werk te definiëren.
Iteration paths: vertegenwoordigen de release-cadans en sprints; een team kiest standaard en huidige iteraties voor de planning.
Team backlogs en boards: elk team kiest welke portfolio-niveaus (Epic, Feature) getoond worden, de stijlen van de kaarten en de kolom-mappings per team, zonder andere teams te beïnvloeden.
Team dashboards: creëer gedeelde zichtbaarheid met widgets voor Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), Lead/Cycle Time-grafieken en aangepaste Analytics-views.

Flow-gebaseerde levering met Kanban en governance

Kanban in Azure Boards modelleert een continue flow van commitment tot voltooiing. Configureer kolommen die overeenkomen met workflow-statussen en splits optioneel kritieke statussen op in Doing/Done-subkolommen om de doorvoer-boekhouding te verbeteren en verborgen wachtrijen te verminderen. Stel expliciete WIP-limieten (Work In Progress) in per kolom en per swimlane; handhaaf deze operationeel—het overschrijden van een limiet leidt tot een verbetergesprek in plaats van een stille groei van de backlog. Gebruik speciale swimlanes (bijvoorbeeld Expedite) om items met hoge prioriteit visueel te scheiden en stel een strakkere WIP-limiet in voor die lane.

De Definition of Done (DoD) verankert kwaliteit en voorspelbaarheid; codeer deze als board policies, verplichte velden of checklists bij specifieke transities, en koppelingen naar acceptatietests. Vereis bijvoorbeeld een ‘Tested By’-link naar een geslaagde Test Case voordat een item naar Done wordt verplaatst, en leg de stappen voor deploymentverificatie vast bij de overgang naar Released.

Gebruik analytics om de gezondheid van de flow te beheren:

Het Cumulative Flow Diagram valideert het WIP-evenwicht en detecteert bottlenecks wanneer de banden breder worden.
Lead Time meet de verstreken tijd van creatie tot voltooiing; Cycle Time richt zich op de tijd vanaf het moment dat een item de status Active krijgt tot aan de voltooiing. De Cycle Time-grafiekwidget rapporteert de verstreken tijd nadat een work item de status Active krijgt, wat aansluit bij bottleneck-analyse.
Throughput-grafieken houden het aantal voltooide items per tijdsperiode bij; monitor de stabiliteit en de trend.

Sprintplanning zet prioriteit om in een ’timeboxed’ commitment. De sprint backlog bevat de PBI’s of User Stories die in de iteratie zijn opgenomen, opgesplitst in Taken met Resterend Werk in uren. Gebruik Sprintcapaciteit om de beschikbaarheid van mensen te modelleren:

Capaciteit per persoon in uren/dag per activiteit (Development, Testing, UX).
Individuele en teamverlofdagen om feestdagen en vakanties weer te geven.
Load balancing op activiteitenniveau door taken aan activiteiten te koppelen en de capaciteit te vergelijken met het geplande werk.

Velocity geeft een samenvatting van de opgeleverde story points per sprint. Gebruik de Velocity-grafiek om een stabiele bandbreedte vast te stellen; vermijd “puntinflatie”. Schakel op product backlogs Forecasting in om te projecteren hoeveel komende iteraties nodig zijn om de backlog weg te werken (‘burn down’) op basis van de historische gemiddelde velocity van het team (gebaseerd op enkele recente sprints) en de iteratielengte. Houd de forecasting eerlijk door gedeeltelijk voltooid werk uit te sluiten en een strikte DoD te handhaven.

Backlog refinement zorgt voor duidelijkheid en relatieve schattingen (‘sizing’):

Acceptatiecriteria: leg duidelijke, testbare verklaringen vast in het Acceptance Criteria-veld van het werkitem; geef de voorkeur aan Given-When-Then om dubbelzinnigheid te verminderen en het testontwerp te versnellen.
Story points: schat de relatieve complexiteit en onzekerheid op het niveau van de requirement; zet punten niet om in uren—taken hebben Resterend Werk.
Relatieve schatting (Planning Poker): gebruik een gedeelde baseline en een reeks (Fibonacci of aangepaste Fibonacci) om snel tot een consensus te komen. Teams kunnen Marketplace-extensies gebruiken om Planning Poker binnen Azure Boards uit te voeren, waarbij schattingen naar de velden Story Points/Effort worden geschreven voor consistente rapportage.

Bugs moeten worden beoordeeld (’triaged’) en ofwel als requirements worden behandeld (geschat met punten en ingepland op de backlog) of als taken binnen de sprint worden afgehandeld; kies één beleid per team om de velocity consistent te houden.

Teamoverstijgende planning, query’s, rapportage, GitHub Projects en DevOps-statistieken

Grote programma’s vereisen inzicht over teams en repositories heen:

Delivery Plans: maak tijdlijnen voor meerdere teams, gefilterd op area/iteration paths. Visualiseer werk per iteratie met afhankelijkheidslijnen (van Predecessor/Successor-links) en markeringen voor mijlpalen (releasedatums, externe verplichtingen). Toon rollup-voortgang van Features en Epics en maak aangepaste velden (bijv. Risico) zichtbaar voor governance-reviews.
Query’s en rapportage: bouw ‘Flat list’-query’s om te beantwoorden ‘welke items voldoen aan deze filters’, ‘Tree of work items’ om door de hiërarchie te navigeren met rollups, en ‘Direct links’-query’s om een enkele link-sprong te analyseren (bijv. Feature → Stories of Bug → commits). Sla query’s op en deel ze, voeg grafieken toe (taart, staaf, trend) en pin ze vast op dashboards. Gebruik voor rapportage op analyse-niveau de Azure DevOps Analytics-service en OData met Power BI om portfolio-burndown, heatmaps voor afhankelijkheidsrisico’s en DORA-visualisaties te produceren. Ingebouwde rapporten omvatten Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time en Sprint Capacity-gebruik.

GitHub Projects integreert planning met Issues en PR’s:

Projectborden: maak Kanban- of tabelweergaven op organisatie- of repository-niveau, definieer aangepaste velden (Status, Iteration, Priority) en filter op team.
Automatiseringsregels: configureer ingebouwde workflows om de Status in te stellen wanneer een Issue of PR wordt geopend, gemerged of gesloten; archiveer voltooide items automatisch; wijs toe of label op basis van veldwijzigingen; en verplaats items tussen weergaven. Combineer met GitHub Actions voor geavanceerde automatiseringen.
Integratie van Issues en PR’s: Issues en PR’s zijn eersteklas items in Projects. Gebruik trefwoorden in PR-beschrijvingen (Fixes #123) om Issues te koppelen en automatisch te sluiten. Status en reviewers zijn zichtbaar op het bord, wat traceerbaarheid van code tot plan mogelijk maakt.

DevOps-statistieken moeten code, deployment en resultaten met elkaar verbinden:

DORA-statistieken:
- Deployment frequency: tel het aantal productie-deployments per dag/week; haal de data uit pipeline release-events.
- Lead time for changes: meet de tijd van code commit (of PR-merge) tot productie-deployment; zorg ervoor dat pipelines deployment-tijdstempels uitzenden en correleer deze met commits.
- Change failure rate: de verhouding van productie-deployments die resulteren in een incident met impact voor de klant of een rollback; integreer met tags voor incidentmanagement en pipeline-resultaten.
- Mean time to restore (MTTR): de verstreken tijd van de start van een incident tot het herstel van de service; baseer dit op monitoring-alerts en de sluittijden van incidenten. Correlleer DORA met Board-analytics (Lead/Cycle time) om te detecteren of de beperking in de planning of in de levering ligt. Gebruik dashboards om beide sets statistieken aan hetzelfde publiek te tonen voor continue verbetering.

Praktisch Probleemscenario

De Advertising-divisie van Microsoft is bezig met het op één lijn brengen van acht cross-functionele teams die een gedeeld platform voor campagnebeheer leveren. De codebase staat in GitHub; de organisatie heeft behoefte aan betrouwbare kwartaaltoezeggingen, duidelijk inzicht in afhankelijkheden, en bruikbare flow- en DORA-statistieken zonder wildgroei aan tools.

Kies het Azure DevOps Agile-proces en configureer teams

Waarom: Agile biedt de hiërarchie Epic > Feature > User Story, die een balans vormt tussen eenvoud en portfolio-rollups. Maak acht teams, elk met een eigen area path en huidige/toekomstige iteration paths, wat autonomie in boards en dashboards mogelijk maakt terwijl rapportage voor de hele organisatie behouden blijft.

Definieer Kanban-governance en bordconfiguratie

Waarom: Continue flow tussen sprints vermindert wachttijd. Configureer kolommen die zijn gekoppeld aan statussen met Doing/Done-splitsingen voor In Progress en Code Review. Stel WIP-limieten in per kolom en voeg een Expedite-swimlane toe met een lagere WIP. Voeg bordbeleid toe dat de Definition of Done (unit tests slagen, PR goedgekeurd, checklist voor deployment-verificatie voltooid) vastlegt om de overgang naar Done te bewaken.

Implementeer backlog refinement en schattingsdiscipline

Waarom: Voorspelbare toezeggingen vereisen consistente inschattingen en duidelijkheid. Leg acceptatiecriteria vast met Given-When-Then op User Stories. Standaardiseer Story Points via Planning Poker (Fibonacci 1–13) met een Azure Boards-extensie, en houd taakinschattingen in ‘Remaining Work’-uren bij om Sprint Capacity te ondersteunen.

Plan sprints met op capaciteit en velocity gebaseerde forecasting

Waarom: Capaciteitsplanning vermindert overcommitment. Voer individuele capaciteiten per activiteit en vrije dagen in. Gebruik de Velocity-grafiek van de laatste zes sprints om een realistisch sprintdoel te stellen. Schakel backlog Forecasting in om te projecteren hoeveel sprints nodig zijn om de kwartaaldoelstellingen van de Epics te bereiken, en zo de verwachtingen van stakeholders op één lijn te brengen.

Stel Delivery Plans op voor teamoverstijgend inzicht

Waarom: Afhankelijkheden en mijlpalen moeten zichtbaar zijn op één enkele tijdlijn. Maak een Delivery Plan dat alle acht teams en portfolioniveaus omvat. Voeg mijlpaalmarkeringen toe voor kwartaalreleases en marktevenementen. Gebruik Predecessor/Successor-links om afhankelijkheidslijnen te tonen en risico’s zichtbaar te maken waar items meerdere iteraties overspannen.

Integreer GitHub Projects voor repository-gerichte uitvoeringsweergaven

Waarom: Ontwikkelaars leven in GitHub; Projects houdt de uitvoeringscontext dicht bij de code. Maak een GitHub Project op organisatieniveau met bord- en tabelweergaven. Voeg automatiseringsregels toe om de Status op In Progress te zetten bij het openen van een PR, op Done bij het mergen van een PR, en om gesloten Issues automatisch te archiveren. Gebruik “Fixes #<id>” in PR’s om gekoppelde Issues te sluiten en de status terug te koppelen naar het bord.

Koppel code en werk voor traceerbaarheid

Waarom: End-to-end traceerbaarheid maakt nauwkeurige rapportage en audits mogelijk. Dwing af dat er in commit-berichten en PR-beschrijvingen wordt verwezen naar de Azure Boards work item ID; gebruik artifact-links op werkitems zodat Delivery Plans en analytics de voortgang van code-activiteit kunnen samenvoegen (rollup).

Instrumenteer flow- en DORA-statistieken op dashboards

Waarom: Gedeelde, geautomatiseerde statistieken stimuleren verbetering. Pin op team-dashboards de CFD-, Lead Time- en Cycle Time-grafieken vast om de flow te beheren. Toon op een programma-dashboard de Velocity, de samenvatting van het Delivery Plan en DORA-statistieken: bereken de deployment frequency en lead time met behulp van pipeline deployment-events uit productiestages; leid de change failure rate en MTTR af door incidenten te taggen en te correleren met deployments. Deze uniforme weergave benadrukt of de beperkingen in de planning (board lead/cycle time) of in de levering (DORA) liggen.

Deze aanpak balanceert teamautonomie (teamspecifieke borden, capaciteit en dashboards) met programma-governance (Delivery Plans, afhankelijkheden en mijlpalen). Azure Boards biedt hiërarchische planning en analytics, GitHub Projects stroomlijnt de dagelijkse tracking voor ontwikkelaars met automatisering gekoppeld aan Issues en PR’s, en DORA-statistieken overbruggen de kloof tussen planning en operationele resultaten voor geloofwaardige, datagestuurde toezeggingen.

← Pakketbeheer en Artefactbeheer · Alle domeinen

Oefen deze vragen → · Getimede oefening op ExamRoll.io →